Remove chrome-extension-resource:// scheme

chrome/common/extensions/docs/templates/articles/contentSecurityPolicy.html

 <h1>Content Security Policy (CSP)</h1>
 
 
 <p>
   In order to mitigate a large class of potential cross-site scripting issues,
   Chrome's extension system has incorporated the general concept of
   <a href="http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html">
     <strong>Content Security Policy (CSP)</strong>
   </a>. This introduces some fairly strict policies that will make extensions
   more secure by default, and provides you with the ability to create and
@@ skipping 269 matching lines @@
   executable resources loaded with an extension's elevated permissions are
   exactly the resources you expect, and haven't been replaced by an active
   network attacker. As <a
   href="http://en.wikipedia.org/wiki/Man-in-the-middle_attack">man-in-the-middle
   attacks</a> are both trivial and undetectable over HTTP, those origins will
   not be accepted.
 </p>
 
 <p>
   Currently, we allow whitelisting origins with the following schemes:
-  <code>blob</code>, <code>filesystem</code>, <code>https</code>,
-  <code>chrome-extension</code>, and <code>chrome-extension-resource</code>.
+  <code>blob</code>, <code>filesystem</code>, <code>https</code>, and
+  <code>chrome-extension</code>.
   The host part of the origin must explicitly be specified for the
   <code>https</code> and <code>chrome-extension</code> schemes.
   Generic wildcards such as <code>https:</code>, <code>https://*</code> and
   <code>https://*.com</code> are not allowed; subdomain wildcards such as
   <code>https://*.example.com</code> are allowed.
   Domains in the <a href="https://publicsuffix.org/list/">Public Suffix list</a>
   are also viewed as generic top-level domains. To load a resource from these
   domains, the subdomain must explicitly be listed. For example,
   <code>https://*.cloudfront.net</code> is invalid, but
   <code>https://XXXX.cloudfront.net</code> and
@@ skipping 150 matching lines @@
   within the script will be regulated by the page's CSP.
 </p>
 
 <p>
   Thus, depending on how you write DOM injected scripts in your extension,
   changes to the page's CSP may affect the behavior of your extension. Since
   content scripts are <em>not</em> affected by the page's CSP, this a great
   reason to put as much behavior as possible of your extension into the content
   script rather than DOM injected scripts.
 </p>