[proposal] harmonize command line flags and config file(s)

[brendankenny]

We need to simplify how options are specified and how you can figure out what options an individual gatherer or audit will be affected by to help users and also (hopefully) help keep our code clearer.

A few steps in that direction I've been thinking about, mostly leaning toward eslint-style configuration:

• have every flag on the command line also be able to be specified in the config
• use the same names for CLI flags and options in the config
• have some subset of these available per-pass where it makes sense (e.g. override throttling)
• have a clear hierarchy over what value wins when set at different levels (see e.g. eslint's "complete configuration hierarchy", which goes inline (per-pass option for us?) > CLI flag > config file)
• support some sort of --print-config which prints a very verbose output of exactly what will be run with the current options from the current location. This is the last safeguard so you can tell what really is going to happen when you run lighthouse both for these flags and for extendable configs added in feat: allow extension of default config #1731

The other side of the first bullet point is allowing every top-level config option to also be specified on the command line, which is something eslint allows. I'm not sure how helpful that really is in practice, but they do at least namespace the options behind e.g. eslint --rule 'quotes: [2, double]' so there isn't a total explosion of possible CLI flags

[patrickhulce]

I was about to add "All options are overridable from CLI" to my features in the doc when you made this 😄

[wardpeet]

would you go for the same name as in cli or make is camelCase as what yargs does in code?
disable-storage-reset => disableStorageReset?