Introduce lock screen app context 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 188 matching lines @@
 The only accepted value is the bool `false` (since true is the default).
 
 ### contexts
 
 The `contexts` property specifies which JavaScript contexts can access the
 feature. All API features must specify at least one context, and only API
 features can specify contexts.
 
 Accepted values are a list of strings from `blessed_extension`,
 `blessed_web_page`, `content_script`, `extension_service_worker`,
-`web_page`, `webui`, and `unblessed_extension`.
+`lock_screen_extension`, `web_page`, `webui`, and `unblessed_extension`.
+
+The `lock_screen_extension` context is used instead of `blessed_extension`
+context for extensions on the Chrome OS lock screen. Other extensions related
+contexts (`blessed_web_page`, `content_script`, `extension_service_worker`,
+`unblessed_extension`) are not expected to be present on the lock screen.
 
 ### default\_parent
 
 The `default_parent` property specifies a feature definition from a complex
 feature to be used as the parent for any children. See also Inheritance.
 
 The only accepted value is the bool `true`.
 
 ### dependencies
 
@@ skipping 229 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.