Parameterize lighthouse concurrency

[emersonthis]

At the moment we force the lighthouse tasks to happen serially by spawning a synchronous child process that blocks the main thread. We're initially avoiding parallelism because there concerns about hardware resource limitations skewing the test results. But for most modern laptops, one-at-a-time is probably too conservative. And because lighthouse is, by far, the most time-consuming part of this script, allowing even two to run in parallel would essentially double the speed of the script. Some things I've read suggest that the safe number of parallel Lighthouses should equal the number of cores in the host device. If this is true, many developers could probably run 4+ safely, which would make the script a LOT more powerful for big sites.

I don't think we want to be responsible for somehow inferring the right amount of parallelism for each user. For small sites, the default to serial is fine. And for power users that need more speed, they can decide for themselves if we provide a param.

• Do the minimal amount of research necessary to understand the performance profile of Lighthouse enough to confirm that allowing parallelism makes.
• Refactor the lighthouse logic to allow potential for parallelism (spoiler: it won't be spawnSync).
• Add a new mechanism by which to limit parallelism. (For example, simplecrawler has config options to add callbacks etc that can control it's rate of crawl. There's probably better ways to do it too)
• Add support for passing the parameter that will adjust this ^
• Document this option in the README, with clear warnings about whatever we know about the potential risks.
• Probably a test to make sure the param does what we want.

[calebeby]

I don't think we want to be responsible for somehow inferring the right amount of parallelism for each user

I think that it is reasonable to infer this (and allow it to be overridden), tools like Jest do this by default, and it is pretty easy to do in node:

require('os').cpus().length