Support API aliases

chrome/common/extensions/api/_features.md

 # Extension Features Files
 
 [TOC]
 
 ## Summary
 
 The Extension features files specify the different requirements for extension
 feature availability.
 
 An **extension feature** can be any component of extension capabilities. Most
@@ skipping 101 matching lines @@
 
 If the parent of a feature is a complex feature, the feature system needs to
 know which parent to inherit from. To do this, add the property
 `"default_parent": true` to one of the feature definitions in the parent
 feature.
 
 ## Properties
 
 The following properties are supported in the feature system.
 
+### alias
+
+The `alias` property is available only for API features. It should be set for
+API features that have an alias. The value should be the name of the alias API

[Devlin, 2016/11/14 18:03:56]

We should describe what an alias is here. :)

[tbarzic, 2016/11/15 04:45:07]

Done.

+feature. The alias feature should have `source` property set to the name of the
+API that it aliased.
+
+For complex features, `alias` property will be set to the `alias` value of the
+first component simple feature that has it set.
+
 ### blacklist
 
 The `blacklist` property specifies a list of ID hashes for extensions that
 cannot access a feature. See ID Hashes in this document for how to generate
 these hashes.
 
 Accepted values are lists of id hashes.
 
 ### channel
 
@@ skipping 126 matching lines @@
 The `session_types` property specifies in which types of sessions a feature
 should be available. The session type describes the type of user that is
 logged in the current session. Session types to which feature can be restricted
 are only supported on Chrome OS - features restricted to set of session types
 will be disabled on other platforms. Also, note that all currently supported
 session types imply that a user is logged into the session (i.e. features that
 use 'session_types' property will be disabled when a user is not logged in).
 
 The accepted values are lists of strings from `regular` and `kiosk`.
 
+### source

[Devlin, 2016/11/14 18:03:56]

I think having an example here would probably be useful.

[tbarzic, 2016/11/15 04:45:07]

Done.

+
+The `source` property is available only for API features. It should be set for
+alias API feature. The value should be the name of the API the alias is
+aliasing. The source API feature should have `alias` property set to the alias
+API name.
+The alias API will inherit schema from the source API, but it will not respect
+the source API child features. To accomplish parity with the source API feature
+children, identical child features should be added for the alias API.
+
+For complex features, `source` property will be set to the `source` value of the
+first component simple feature that has it set.
+
 ### whitelist
 
 The `whitelist` property specifies a list of ID hashes for extensions that
 are the only extensions allowed to access a feature.
 
 Accepted values are lists of id hashes.
 
 ## ID Hashes
 
 Instead of listing the ID directly in the whitelist or blacklist section, we
@@ skipping 104 matching lines @@
 at runtime, this has the added benefit of allowing us to validate at compile
 time rather than needing a unittest (or allowing incorrect features).
 
 In theory, invalid features should result in a compilation failure; in practice,
 the compiler is probably missing some cases.
 
 ## Still to come
 
 TODO(devlin): Add documentation for extension types. Probably also more on
 requirements for individual features.