New: support specifying extensions in the config (fixes #10828)

[g-plane]

What is the purpose of this pull request? (put an "X" next to item)

Add something to the core

What changes did you make? (Give an overview)
Support specifying extensions in configuration files.

The extensionRegExp property on FileEnumerator instance is removed. Instead, getExtensionRegExp method is introduced. (This isn't a breaking change because it isn't part of public APIs.)
This enables that ESLint reads configuration file and retrieves extensions on demand, instead of generating extensionRegExp in the constructor of FileEnumerator.

Is there anything you'd like reviewers to focus on?

• Does this change need more tests?
• Even specifying any extensions in configuration file, .js is always included. Is this behavior correct? Or should it be overrided?

[mysticatea]

Hi, @g-plane. Thank you for your work!

However, this direction is different a bit from the current consensus. As mentioned in #10828 (comment), we have RFC20 and RFC22 as approved approach. If you want to support the extentions top-level property, would you send an RFC similar to RFC22?

[g-plane]

It's still in progress so it may be different with RFC, however, this PR is modeled after RFC20. Is this direction wrong?

[mysticatea]

It's no problem if the add of the extentions top-level property is temporary. I wanted to clarify because the issue description doesn't mention about WIP.

To make sure, RFC20 doesn't add any property to config files.

[g-plane]

So should I close this if it's too early?

[mysticatea]

No, feel free to continue to work on this. Just I wanted to clarify.

[g-plane]

Should I send an RFC about adding this property before continuing?

[mysticatea]

However, this direction is different a bit from the current consensus. As mentioned in #10828 (comment), we have RFC20 and RFC22 as approved approach. If you want to support the extentions top-level property, would you send an RFC similar to RFC22?

#12555 (comment)