Introduce session type parameter to extension features

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 235 matching lines @@
 The only accepted value is the bool `true`.
 
 ### platforms
 
 The `platforms` property specifies the properties the feature should be
 available on.
 
 The accepted values are lists of strings from `chromeos`, `mac`, `linux`, and
 `win`.
 
+### session\_types
+
+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 - feature restricted to set of session types

[Devlin, 2016/09/13 17:37:45]

nit: s/features/feature

[tbarzic, 2016/09/13 17:55:12]

Done.

+will be disabled on other platforms. Also, note that all currently supported
+session types imply that a user is logged into the session.

[Devlin, 2016/09/13 17:37:45]

Mention what the value is when the user is *not* logged in?

Also, this still makes me a little nervous, because it means things like the
following break:
feature: {
  session_types: [regular]
}
feature.child: {
  session_types: [???]  // How do I get all session types?
}

I'm okay addressing that at a later date, but keep it in mind.

[tbarzic, 2016/09/13 17:55:12]

That one is not currently supported (as there is no need to enable an API only
when a user is not logged in).
(except for handful of exceptions (Chromevox and easy unlock app, afaik),
extensions are not allowed before a user is logged in on Chrome OS)
If this has to be supported, we could add another enum value 'all', or maybe set
the value to session_types: <all> (this could apply to other feature properties,
e.g. platforms)

[Devlin, 2016/09/13 18:13:50]

I understand we don't offer it as a value, but it's important to note that if a
user is not logged in, it will not be considered any of the session types.  This
is somewhat implied by the last sentence already, but I'd like it to be
explicit.
Many properties support all - e.g. contexts.  The difference is that "all" for
something like platforms just encompasses the platforms that can be specified
already - i.e., I can specify win, linux, chromeos, and mac.  For session types,
that's not the case.  And I think it's very confusing for 'all' to imply more
than the collection of available enums.

[tbarzic, 2016/09/13 18:25:40]

Done.
Ack

+
+The accepted values are lists of strings from `regular` and `kiosk`.
+
 ### 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.