Remove Chromium's custom closure runner.

third_party/closure_compiler/externs/chrome_extensions.js

 //    SSSSSSSSSSSSSSS TTTTTTTTTTTTTTTTTTTTTTT     OOOOOOOOO     PPPPPPPPPPPPPPPPP
 //  SS:::::::::::::::ST:::::::::::::::::::::T   OO:::::::::OO   P::::::::::::::::P
 // S:::::SSSSSS::::::ST:::::::::::::::::::::T OO:::::::::::::OO P::::::PPPPPP:::::P
 // S:::::S     SSSSSSST:::::TT:::::::TT:::::TO:::::::OOO:::::::OPP:::::P     P:::::P
 // S:::::S            TTTTTT  T:::::T  TTTTTTO::::::O   O::::::O  P::::P     P:::::P
 // S:::::S                    T:::::T        O:::::O     O:::::O  P::::P     P:::::P
 //  S::::SSSS                                                     P::::PPPPPP:::::P
 //   SS::::::SSSSS       This file is generated. To update it,    P:::::::::::::PP
 //     SSS::::::::SS          run roll_closure_compiler.          P::::PPPPPPPPP
 //        SSSSSS::::S                                             P::::P
@@ skipping 31 matching lines @@
  * B. Optional parameters
  * C. Pseudo-types
  * D. Events
  * E. Nullability
  * F. Private APIs
  * G. Enums
  *
  * The best practices for each are described in more detail below.  It
  * should be noted that, due to historical reasons, and the evolutionary
  * nature of this file, much this file currently violates the best practices
- * described below. As changed are made, the changes should adhere to the
+ * described below. As changes are made, the changes should adhere to the
  * best practices.
  *
  * A. When to Add Packages to this File?
  * Packages in chrome.experimental.* should *not* be added to this file. The
  * experimental APIs change very quickly, so rather than add them here, make a
  * separate externs file for your project, then move the API here when it moves
  * out of experimental.
  *
  * Some non-experimental APIs are still evolving or are not full documented. It
  * is still advantageous to include these in this file as doing so avoids a
@@ skipping 56 matching lines @@
  * creates a nullable record-type typedef so ! has the same meaning in usages
  * as it does for real types.
  *
  * For #2, use a standard constructor, even though no constructor is provided
  * and extension writers will never instantiate an instance, as using a first
  * class type provides the strongest type checking. For example, see the Port
  * type defined at http://developer.chrome.com/apps/runtime.html#type-Port.
  * Always qualify the type name to reduce top-level pollution in this file:
  *
  *   Do:
- *        chrome.extension.Port = function() {}
+ *        chrome.runtime.Port = function() {}
  *   Don't:
  *        function Port() {}
  *
  * Note that, unfortunately, the actual Port class definition in this file
  * does not follow this recommendation.
  *
  * For #3, use {!Object}, that is, a bag of properites. This is a sad reality
  * given that the Chrome extensions do not document a real type. It is tempting
  * to define a real-type within this file and treat this situation as identical
  * to #2, but that means a new type is being defined in this file and developers
@@ skipping 6442 matching lines @@
  * @see https://developer.chrome.com/extensions/debugger.html#type-Debuggee
  * @constructor
  */
 function Debuggee() {}
 
 
 /** @type {number} */
 Debuggee.prototype.tabId;
 
 
-
 /**
  * @see https://developer.chrome.com/extensions/contentSettings.html#type-ResourceIdentifier
  * @constructor
  */
 function ResourceIdentifier() {}
 
 
 /** @type {string} */
 ResourceIdentifier.prototype.id;
 
@@ skipping 4030 matching lines @@
 /** @return {boolean} */
 chrome.downloads.DeterminingFilenameEvent.prototype.hasListeners =
     function() {};
 
 
 /**
  * @type {!chrome.downloads.DeterminingFilenameEvent}
  * https://developer.chrome.com/extensions/downloads#event-onDeterminingFilename
  */
 chrome.downloads.onDeterminingFilename;