feat: support for modifier

[ota-meshi]

I was working on an experimental implementation of the RegExp Modifiers. I'm not sure yet if this implementation can be merged as-is, but I'm opening a PR to share my AST ideas as well.

https://github.com/tc39/proposal-regexp-modifiers

[RunDevelopment]

A bit of feedback from my first impression of the AST (I haven't looked at the parser implementation yet):

1. Group#modifiers: Modifiers | null: When is modifiers null? Is it null when modifiers are impossible (legacy regexes) or when there are no modifiers (e.g. /(?:foo)/u)? What about /(?-:foo)/u?
2. Modifiers#add and Modifiers#remove: What does null mean for them? Can both be null? If null means "no flags", then why not have a ModifierFlags with all flags set to false?

[ota-meshi]

Thank you for your comment!

Group#modifiers: Modifiers | null: When is modifiers null? Is it null when modifiers are impossible (legacy regexes) or when there are no modifiers (e.g. /(?:foo)/u)? What about /(?-:foo)/u?

Regexps without modifiers will be null. For example, modifiers of (?:x) is null. (?-:x) will result in a parsing error.

Modifiers#add and Modifiers#remove: What does null mean for them? Can both be null? If null means "no flags", then why not have a ModifierFlags with all flags set to false?

I thought that nodes with no width should be avoided, but after re-checking it, it seems that nodes with no width already exist the nodes generated by regexpp. For example, a Flags node without flags has no width.
For consistency, it seems necessary to set a ModifierFlags node that sets all flags to false, as you say. I will make that change later.

[RunDevelopment]

Regexps without modifiers will be null. For example, modifiers of (?:x) is null.

I see, makes sense.

(?-:x) will result in a parsing error.

Ah, my bad. I only looked at the grammar itself and not its early errors.