Introduce computedArtifacts

[paulirish]

There are a few in-between artifacts that have been generated from the trace & networkRecords. However they can be lazily created, which simplifies the scheduling of items like speedline, and reduces complexity when importing artifacts from the config.

Additionally, this also means we can cache the results of our computedArtifacts, which will speed up generation of speedline, DevtoolsTimelineModel, and TracingModel.

This PR moves 3 gatherers into be computedArtifacts: speedline, screenshots, and critical network chains.

Once landed, I'll followup with porting DevtoolsTimelineModel, and TracingModel into the same setup. (With the latest version of speedline, we can now pass a complete DevtoolsTimelineModel into it, the same we'll share for our own measurements. This will take care of another ~1-4s of latency during reporting)

fixes #542

[paullewis]

I'm not clear on exactly what the change proposes. How does computedArtifacts sit alongside artifacts?

[paulirish]

@paullewis

#542 has some backstory, but I'll elaborate here. This was motivated by two things:

1. Currently a lighthouse run builds a traceviewer model multiple times (in EIL and TTI). It creates a devtoolstimelinemodel multiple times as well (user-timings, screenshots, and again inside of speedline). Each of these models builds costs 700ms-2000ms depending on the trace. To speed up the run, I'd like to make sure we only build our models just once and pass that around.
   • This would mean turning these models into gatherers. But that's unfortunate as they don't really have to be scheduled against a pass. And I'd prefer to not build these models in-between our gatherers.
   • More importantly, screenshots depends on devtoolstimelinemodel (and speedline soon will), but as gatherers they'll all be siblings, which will lead to some awkward configuration to manage this scheduling.
2. When lighthouse accepts a trace as input it has to reach back into speedline in order to present it as an artifact. And then with the change I just described above, it will have to do the same but for all of these components, sequenced correctly. This hardcodes too much knowledge about our artifact dependencies right into our configuration management.

How does computedArtifacts sit alongside artifacts?

This PR makes a semantic change between these two categories.

• gatherers all speak directly to the browser and collect data. All of them talk to the protocol
• computed artifacts do not talk to the protocol. They take either a trace or networkRecords and generate another artifact that's of value to more than 1 audits. (if they're only ever going to be useful to 1 audit, then their work might as well be done inside the audit)

And lastly, functionally, this PR adds an async interface onto the artifacts object that allows any audit to request one of these computedArtifacts. artifacts.requestSpeedline(trace).then( ....