Initial skeleton for System Indicator API

chrome/common/extensions/permissions/api_permission.h

Index: chrome/common/extensions/permissions/api_permission.h
diff --git a/chrome/common/extensions/permissions/api_permission.h b/chrome/common/extensions/permissions/api_permission.h
index 07d0631159b3387a5017838aafa534681072c45a..a022b27139e0922a506130f59b92ab12f2bfe58d 100644
--- a/chrome/common/extensions/permissions/api_permission.h
+++ b/chrome/common/extensions/permissions/api_permission.h
@@ -94,6 +94,7 @@ class APIPermission {
     kStorage,
     kSyncFileSystem,
     kSystemPrivate,
+    kSystemIndicator,

[not at google - send to devlin, 2012/11/16 17:42:04]

The permission for the system indicator API should come from the
system_indicator manifest property (requiring both that and a permission would
be redundant).

Implementation-wise that means adding it to the kNonPermissionFunctionNames
array in chrome/common/extensions/permissions/permission_set.cc.

[dewittj, 2012/11/16 19:13:57]

I'm not sure all system indicator apps are going to have the manifest section,
for example they might dynamically generate their icons from a canvas.  Is this
primarily for parity with browseraction?

[not at google - send to devlin, 2012/11/16 19:21:09]

The same could be said for browser actions. Generally speaking, we should
encourage apps/extensions to declare their icons up-front since it's likely that
mostly that's what they'll want to do, and it saves extensions/apps needing to
start themselves in order to set an icon (and would save on UI jank).

Browser actions (and page actions) are perfectly happy to just have a blank
manifest section though, forcing them to set it themselves.

It'll be a bit weird only supporting the "default icons" property of it, but
perhaps we'll want to add more features to it later anyway (like
"default_enabled" perhaps), so I think that's fine.

     kTab,
     kTabCapture,
     kTerminalPrivate,