Improve TFTT (Time to First Test Title)

[jamestalmage]

@kentcdodds put it best. Once AVA starts running tests, it screams. But it feels like there is a long wait for that first test to spit out.

AVA would "feel" a lot faster if we got to our first test sooner. There are a couple things that need to happen for that to be a reality:

• API needs to be refactored to run tests in smaller batches. Running additional tests as tests from the first batch begin to complete. I have async-task-pool ready to assist in this, it's just a matter of refactoring api.js to handle this.
• A big hurdle will be accommodating our sticky .only behavior. babel-plugin-ava-test-data can help by attempting to provide some static analysis of which tests might have a .only call in them, but there are situations where it could be tricked. We need to decide how to handle that. As a temporary solution, I say we make batch-size configurable, and default it to number-of-tests. If users reconfigure batch-size to a number lower than number-of-tests, then it breaks .only stickiness (.only will go back to the old behavior of only affecting the file it is in). This is just to get batching out the door, and into the hands users who really need it. Once it's shipped, we can incorporate static analysis of .only calls and associated fallback logic.
• Once batching is landed, it is a pretty easy win to refactor api.js to scan for which tests have valid cache entries in caching-precompiler. Tests we don't need to recompile should be launched first.
• I'm not entirely sure we need to wait for stats to be communicated back to the parent process before the Runner starts running any tests. Especially once we start incorporating static analysis. It doesn't make a whole lot of sense with batching.

[vadimdemedes]

Good points!

As for async-task-pool, we can use Bluebird's concurrency parameters instead of a new module, plus I'm not a fan of its API (function returning a function).

Tests we don't need to recompile should be launched first.

This one can be accomplished soonest of all, like this idea.

[jamestalmage]

we can use Bluebird's concurrency parameters instead of a new module

Fair enough. async-task-pool really only becomes valuable when there is an expensive resource tied to the concurrency (i.e. delegating tasks to long-lived child-processes, where the child-process only handles a single task at a time, but will handle multiple tasks before being closed). Bluebird disposers might do just as well as async-task-pool on that issue as well.

[jamestalmage]

Tests we don't need to recompile should be launched first.

This one can be accomplished soonest of all, like this idea

No point until we have batching. Right now, it doesn't matter which order we launch them in, we wait for the stats on ALL of them before starting up tests.