I forgot that this wasn't supported in Dart 1.24 .

Closes #781

See the internal bug b/73723892

These tests have been flaking all over the place, and with the total
lack of support for content shell coming so soon it doesn't make sense
to spend the resources tracking down and fixing the root cause.

Add a SuitePlatform class

This clarifies the distinction between TestPlatform and SuitePlatform,
and uses a more specific word rather than a more general one.
Unfortunately, it does mean that we have some user-facing
interfaces (the --platform flag, the override_platforms and
define_platforms configuration fields) that now use different
terminology than the test runner.

It would be possible to migrate those to refer to "runtime" as well,
but seeing as --platform in particular is very widely-used *and*
matches up nicely with --preset (-p vs -P) I'm inclined to think it's
not worth the effort.

This encapsulates all the information about the platform on which a
suite runs, and which platform selectors can select for. Currently it
just includes the runtime and the operating system, but eventually it
could include whether we're running internally to Google, or which
compiler is in use.

Also re-enable headless mode by default.

See #772 for an example of a failure that only occurs in headless
mode.

This wasn't caught by Travis due to our workaround for #599.

Clean up the way source maps are passed to workers

This allows us to remove a JS-specific option from the cross-platform
serializeSuite() API.

This allows plugins to create stream channels with the worker before
the test suite is fully loaded.

This makes the configuration zone-scoped rather than global to a
worker.

Partially addresses #711

Fix tests

We were using Dartium settings due to what I assume was a copy-paste
error on my part. I don't think this actually affected anything but
tests, since when running tests we never used the default
ExecutableSettings.

This will allow us to run those tests with Dart 2, where Dartium isn't
supported.

The memory leak occurs when window.parent is accessed through
dart:html, so we access it directly through JS interop instead.

Closes #724

We weren't destroying our references to `iframe`s after removing those
frames from the DOM, so we would slowly accumulate more and more
frames as time went on.

Partially addresses #724

Closes #753

Prepare for fix of https://github.com/dart-lang/sdk/issues/31963

Closes #742

This folds frames from core libraries and packages we don't care
about, but leaves test frames as-is.

Also fix a related documentation error.

Closes #740