Add support for NumericUnderscores extensions from CLI/config

[9999years]

Closes #1434

Supercedes #1435, updated for latest master.

[zliu41]

I'll defer this to @ndmitchell. I think the intention of passing extensions to HLint is for parsing, not for deciding if a hint should trigger, although it seems reasonable to do the latter.

Even if we decide to do that, this PR will need a few more updates:

• I'm not seeing how you are passing the additional extensions from the Yaml config to the places that need them.
• Since the additional extensions are from the HLint config and not tied to individual modules, it doesn't seem to make sense to associate them with ModuleEx.
• Need to add some tests.

[parsonsmatt]

So the provenance of these extensions is in ParseFlags. This is not passed to hints themselves.

The type of DeclHint is:

type DeclHint = Scope -> ModuleEx -> LHsDecl GhcPs -> [Idea]

If we want to propagate this information, we have essentially three choices:

1. Smuggle it in ModuleEx.
2. Smuggle it in Scope.
3. Add another function argument here for the whole hlint configuration (ParseFlags ? and [Setting] maybe?)

Scope is, already, just a convenience/performance/cache wrapper around information that is extracted directly from the contents of a ModuleEx. Here is definition and logic to create.

I think one could argue that Scope is a more reasonable place for this than ModuleEx, but I'd go further: Scope should be part of ModuleEx directly. After all, scopeCreate is called on the ModuleEx - which means that we have already lost the ParseFlags information, if it is not present on ModuleEx.

IMO, a ModuleEx represents "what we know about a parsed module":

-- | Result of 'parseModuleEx', representing a parsed module.
newtype ModuleEx = ModuleEx {
    ghcModule :: Located (HsModule GhcPs)
}

But we don't know - what extensions were enabled while parsing this module?

I think "rearchitecting the way we pass flags around in hlint and breaking the whole API for hints" is probably not appropriate for this PR. If we extend ModuleEx, then we pave the way for further additions to ModuleEx as "the" place to put information relevant to a module. If we extend Scope, then we need to plumb that through anyway, possibly through ModuleEx resulting in duplication. But neither option prevent or impede a more serious refactoring in how this code works.