Installer changes for app host to support command line install from webstore

chrome/installer/setup/install_worker.cc

Index: chrome/installer/setup/install_worker.cc
diff --git a/chrome/installer/setup/install_worker.cc b/chrome/installer/setup/install_worker.cc
index 9f9ccad03f7c705cd2adefa9537e5e05674cd275..9d2eaa660294b84941309e2057ffcfe1bee1188d 100644
--- a/chrome/installer/setup/install_worker.cc
+++ b/chrome/installer/setup/install_worker.cc
@@ -188,7 +188,7 @@ void AddInstallAppCommandWorkItems(const InstallerState& installer_state,
   } else {
     CommandLine cmd_line(
         installer_state.target_path().Append(installer::kChromeAppHostExe));
-    cmd_line.AppendSwitchASCII(::switches::kAppsInstallFromManifestURL, "%1");
+    cmd_line.AppendSwitchASCII(::switches::kInstallFromWebstore, "%1");

[gab, 2012/09/18 16:44:21]

According to the comments on those switches: kAppsInstallFromManifestURL took a
URL while kInstallFromWebstore takes an app ID... are app IDs URL? was this
previously broken? (i.e. when is this invoked and what is "%1"?).

[asargent_no_longer_on_chrome, 2012/09/18 16:59:14]

This code was written in advance of chrome actually supporting the
kAppsInstallFromManifestURL flag, so passing it was just a no-op.

I was tasked with actually implementing that functionality in chrome, but it
turned out to be easier to pass an app id than a URL to an app, because we
already had inline install code
(https://developers.google.com/chrome/web-store/docs/inline_installation) which
just needs the id. So the code we'll be using to call the installer will just
pass this id instead of a URL. 

 
     AppCommand cmd(cmd_line.GetCommandLineString());
     cmd.set_sends_pings(true);