Adds browser preferences to configure first-run flow on Windows 8.

chrome/installer/util/master_preferences_constants.cc

Index: chrome/installer/util/master_preferences_constants.cc
diff --git a/chrome/installer/util/master_preferences_constants.cc b/chrome/installer/util/master_preferences_constants.cc
index 8884ce058734e2ea613c404d9e8c3a6eb5d5997e..a59c4f2ae60381429a4033644ead096d73d076f8 100644
--- a/chrome/installer/util/master_preferences_constants.cc
+++ b/chrome/installer/util/master_preferences_constants.cc
@@ -31,6 +31,8 @@ namespace master_preferences {
   const char kLogFile[] = "log_file";
   const char kMakeChromeDefault[] = "make_chrome_default";
   const char kMakeChromeDefaultForUser[] = "make_chrome_default_for_user";
+  const char kSuppressFirstRunDefaultBrowserPrompt[] =
+      "suppress_first_run_default_browser_prompt";

[gab, 2012/07/24 17:43:16]

I think something more generic like non_interactive_first_run is better as OEMs
that don't want this now won't want other types of interactive first runs we can
come up with in the future and having one pref to disable them all is easier imo
(and renaming a pref later is a pain as it'll be hardcoded all over the
enterprise guys' scripts).

[motek., 2012/07/25 10:08:58]

This one is quite specific now (after merging it with that other flag) and
influences indirectly showing (or not) of the butter bar on first run. 
I don't feel strongly about naming, but I am afraid it may cause extra
confusion. 
Besides, what if someone comes up with another modal flow that will absolutely
need to be controlled separately? Then we will have a pref that does this one
dialog but purports to control everything... 

[grt (UTC plus 2), 2012/07/25 10:54:55]

I think the specific name is appropriate given the complex nature of the
preference.  It's a specific knob for a specific feature request.

   const char kMsi[] = "msi";
   const char kMultiInstall[] = "multi_install";
   const char kRequireEula[] = "require_eula";