Add on_os and on_platform fields.

doc/package_config.md

 Each package may include a configuration file that applies to the package as a
 whole. This file can be used to provide custom defaults for various options, to
 define configuration for multiple files, and more.
 
 The file is named `dart_test.yaml` and lives at the root of the package, next to
 the package's pubspec. Like the pubspec, it's a [YAML][] file. Here's an
 example:
 
 [YAML]: http://yaml.org/
 
@@ skipping 20 matching lines @@
   * [`skip`](#skip)
   * [`test_on`](#test_on)
 * [Runner Configuration](#runner-configuration)
   * [`paths`](#paths)
   * [`filename`](#filename)
   * [`platforms`](#platforms)
   * [`concurrency`](#concurrency)
   * [`pub_serve`](#pub_serve)
   * [`reporter`](#reporter)
 * [Configuring Tags](#configuring-tags)
+  * [`tags`](#tags)
   * [`add_tags`](#add_tags)
+* [Configuring Platforms](#configuring-platforms)
+  * [`on_os`](#on_os)
+  * [`on_platform`](#on_platform)
 
 ## Test Configuration
 
 There are two major categories of configuration field: "test" and "runner". Test
 configuration controls how individual tests run, while
 [runner configuration](#runner-configuration) controls the test runner as a
 whole. Both types of fields may be used at the top level of a configuration
 file. However, because different tests can have different test configuration,
-only test configuration fields may be used to
-[configure tags](#configuring-tags).
+only test configuration fields may be used to [configure tags](#tags) or
+[platforms](#on_platform).
 
 ### `timeout`
 
 This field indicates how much time the test runner should allow a test to remain
 inactive before it considers that test to have failed. It has three possible
 formats:
 
 * The string "none" indicates that tests should never time out.
 
 * A number followed by a unit abbreviation indicates an exact time. For example,
@@ skipping 43 matching lines @@
 
 ```yaml
 tags:
   chrome:
     skip: "Our Chrome launcher is busted. See issue 1234."
 ```
 
 ### `test_on`
 
 This field declares which platforms a test supports. It takes a
-[platform selector][] and only allows tests to run on platforms that match the
-selector. It's often used with [specific tags](#configuring-tags) to ensure that
-certain features will only be tested on supported platforms.
+[platform selector][platform selectors] and only allows tests to run on
+platforms that match the selector. It's often used with
+[specific tags](#configuring-tags) to ensure that certain features will only be
+tested on supported platforms.
 
-[platform selector]: https://github.com/dart-lang/test/blob/master/README.md#platform-selectors
+[platform selectors]: https://github.com/dart-lang/test/blob/master/README.md#platform-selectors
 
 ```yaml
 tags:
   # Internet Explorer doesn't support promises yet.
   promises: {test_on: "browser && !ie"}
 ```
 
 The field can also be used at the top level of the configuration file to
 indicate that the entire package only supports a particular platform. If someone
 tries to run the tests on an unsupported platform, the runner will print a
@@ skipping 86 matching lines @@
 This field indicates the default reporter to use. It may be set to "compact",
 "expanded", or "json" (although why anyone would want to default to JSON is
 beyond me). It defaults to "expanded" on Windows and "compact" everywhere else.
 
 ```yaml
 reporter: expanded
 ```
 
 ## Configuring Tags
 
+### `tags`
+
 The `tag` field can be used to apply [test configuration](#test-configuration)
 to all tests [with a given tag][tagging tests] or set of tags. It takes a map
 from tag selectors to configuration maps. These configuration maps are just like
 the top level of the configuration file, except that they may not contain
 [runner configuration](#runner-configuration).
 
 [tagging tests]: https://github.com/dart-lang/test/blob/master/README.md#tagging-tests
 
 ```yaml
 tags:
@@ skipping 31 matching lines @@
 Tag configuration is applied at whatever level the tag appears—so if a group is
 tagged as `integration`, its timeout will take precedence over the suite's
 timeout but not any tests'. If the group itself had a timeout declared, the
 group's explicit timeout would take precedence over the tag.
 
 If multiple tags appear at the same level, and they have conflicting
 configurations, the test runner *does not guarantee* what order they'll be
 resolved in. In practice, conflicting configuration is pretty unlikely and it's
 easy to just explicitly specify what you want on the test itself.
 
+This field counts as [test configuration](#test-configuration).
+
 ### `add_tags`
 
 This field adds additional tags. It's technically
 [test configuration](#test-configuration), but it's usually used in more
 specific contexts. For example, when included in a tag's configuration, it can
 be used to enable tag inheritance, where adding one tag implicitly adds other as
 well. It takes a list of tag name strings.
 
 ```yaml
 tags:
   # Any test that spawns a browser.
   browser:
     timeout: 2x
 
   # Tests that spawn specific browsers. These automatically get the browser tag
   # as well.
   chrome: {add_tags: [browser]}
   firefox: {add_tags: [browser]}
   safari: {add_tags: [browser]}
   ie: {add_tags: [browser]}
 ```
+
+## Configuring Platforms
+
+There are two different kinds of platform configuration.
+[Operating system configuration](#on_os) cares about the operating system on
+which test runner is running. It sets global configuration for the runner on
+particular OSes. [Test platform configuration](#on_platform), on the other hand,
+cares about the platform the *test* is running on (like the
+[`@OnPlatform` annotation][@OnPlatform]). It sets configuration for particular
+tests that are running on matching platforms.
+
+[@OnPlatform]: https://github.com/dart-lang/test/blob/master/README.md#platform-specific-configuration
+
+### `on_os`
+
+This field applies configuration when specific operating systems are being used.
+It takes a map from operating system identifiers (the same ones that are used in
+[platform selectors][]) to configuration maps that are applied on those
+operating systems. These configuration maps are just like the top level of the
+configuration file, and allow any fields that may be used in the context where
+`on_os` was used.
+
+```yaml
+on_os:
+  windows:
+    # Both of these are the defaults anyway, but let's be explicit about it.
+    color: false
+    runner: expanded
+
+    # My Windows machine is real slow.
+    timeout: 2x
+
+  # My Linux machine has SO MUCH RAM.
+  linux:
+    concurrency: 500
+```
+
+This field counts as [test configuration](#test-configuration). If it's used in
+a context that only allows test configuration, it may only contain test
+configuration.
+
+### `on_platform`
+
+This field applies configuration to tests that are run on specific platforms. It
+takes a map from [platform selectors][] to configuration maps that are applied
+to tests run on those platforms. These configuration maps are just like the top
+level of the configuration file, except that they may not contain
+[runner configuration](#runner-configuration).
+
+```yaml
+# Our code is kind of slow on Blink and WebKit.
+on_platform:
+  chrome || safari: {timeout: 2x}
+```
+
+**Note**: operating system names that appear in `on_platform` refer to tests
+that are run on the Dart VM under that operating system. To configure all tests
+when running on a particular operating system, use [`on_os`](#on_os) instead.
+
+This field counts as [test configuration](#test-configuration).