Pretty-print regular expression options

[flavorjones]

Given the trivial program

/asdf/
/asdf/i
/asdf/m
/asdf/x
/asdf/o
/asdf/imxo

the pretty-print for each of these regular expressions literals is identical:

(program
  (statements
    ((regexp_literal ((tstring_content "asdf"))),
      (regexp_literal ((tstring_content "asdf"))),
      (regexp_literal ((tstring_content "asdf"))),
      (regexp_literal ((tstring_content "asdf"))),
      (regexp_literal ((tstring_content "asdf"))),
      (regexp_literal ((tstring_content "asdf"))))))

even though they have different options (which are present in the AST node as part of the ending attribute).

I'm happy to submit a PR to change this behavior if you a) think it would be valuable, and b) would be so kind as to suggest the sexp structure you'd like to emit in this case.

[kddnewton]

Please do! I would add it to the visit_regexp_literal method with a field call. Something like field("options", node.ending[1..-1]) should do the trick. (ending in this case is the close of the regex, so it could start with / or } or > or whatever else.)