Add the ability to add tags in the test config.

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 18 matching lines @@
   * [`verbose_trace`](#verbose_trace)
   * [`js_trace`](#js_trace)
 * [Runner Configuration](#runner-configuration)
   * [`paths`](#paths)
   * [`filename`](#filename)
   * [`platforms`](#platforms)
   * [`concurrency`](#concurrency)
   * [`pub_serve`](#pub_serve)
   * [`reporter`](#reporter)
 * [Configuring Tags](#configuring-tags)
+  * [`add_tags`](#add_tags)
 
 ## 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).
@@ skipping 162 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.
+
+### `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]}
+```