Consider always filtering configs to allow extra gatherers that won't run by default

[brendankenny]

Right now we only filter configs when onlyAudits, onlyCategories, or skipAudits are set.

Some of the proposed plugins will need a gatherer. It seems ok to include in core if they're generally useful (e.g. the proposed IFrameElements), but they are doing unnecessary work in the default case since no audits depend on their output.

If we do filter configs by default (essentially setting --onlyAudits=[...defaultAudits] if no other filter flags are set), that would allow us to keep those extra gatherers in the default config with no overhead since they'll be filtered out in the usual case. Then running plugins wouldn't require a custom config (only --plugins lighthouse-plugin-whatever flag).

Downsides/caveats:

• harder to understand what actually runs with the default config when reading default-config.js (you'd need to run --print-config to see what will actually happen)
• when debugging or writing a new gatherer you'd have to include an audit using it for the gatherer to actually run
• if a gatherer is fairly minimal, is there much of a win in overhead vs some of our already very large gatherers? Maybe we should wait until we have a gatherer to support a plugin that is actually heavyweight

(so I'm not 100% sold on this yet, but it would have benefits)

[connorjclark]

would want a way to cancel this behavior: ex: I am using lh to gather artifacts and don't really care about the audits (idk maybe someone does this).

[patrickhulce]

We'll make sure to handle this as part of #11313 for automatic filtering in modes, but we won't be pursuing this in current Lighthouse gathering flow.