Previously, it was not possible to create fixtures that loaded
asynchronously. It was possible to work around this limitation on the
JVM by awaiting on futures, but there was no workaround for Scala.js.
This commit adds support to return futures (and anything that converts
to futures) from the beforeAll/beforeEach/afterEach/afterAll methods.

Supersedes scalameta#418. This commit is
inspired by that PR but uses a different approach:

- No new `AsyncFixture[T]` type. This simplies the logic in
  `MUnitRunner` and reduces the size of the MUnit public API.
  The downside is that we introduce a breaking change to the existing
  `Fixture[T]` API, which will require bumping the version to v1.0.0
  for the next release.
- This approach supports any `Future`-like values by hooking into the
  default evaluation of test bodies via `munitValueTransforms`.

Co-authored-by: Daniel Esik <[email protected]>

A bug in Scala 2.11/2.12 made `TimeoutSuite` fail with the new async
fixtures. This commit changes how we implement `munitTimeout` to race
two futures instead of calling `Await.result`.

This test case was causing CI failures on Linux that I wasn't able to
reproduce on my local MacBook.

Previously, the test suite was using a parasitic execution context.

Previously, the `Fixture` lifecycle methods returned `Any`, which meant
that auto-completions would insert `Any` in the result type when
auto-generating implementation of a fixture. Now, the `Fixture[T]` class
has `Unit` as result types for consistency with older versions of MUnit.
Instead, we introduce `AnyFixture[T]` which only needs to be used when
comibing a list of `Fixture[T]` and `FutureFixture[T]` (along with
    3rdparty fixture classes).