Create profile .ico file on profile creation

chrome/browser/profiles/profile.cc

Index: chrome/browser/profiles/profile.cc
diff --git a/chrome/browser/profiles/profile.cc b/chrome/browser/profiles/profile.cc
index 9c3b711324c2c066dee4909998b4984c3ea08b02..37347af010f428d3407f2fc98528edb50f65d94c 100644
--- a/chrome/browser/profiles/profile.cc
+++ b/chrome/browser/profiles/profile.cc
@@ -104,6 +104,10 @@ void Profile::RegisterUserPrefs(user_prefs::PrefRegistrySyncable* registry) {
       prefs::kDefaultApps,
       "install",
       user_prefs::PrefRegistrySyncable::UNSYNCABLE_PREF);
+  registry->RegisterIntegerPref(
+      prefs::kProfileIconVersion,
+      0,

[gab, 2013/06/18 15:36:58]

Why is this an integer? As it is right now it is used as boolean (i.e. only
checked on profile creation).

Having it be an integer only feels right if there is code to update the icon if
kCurrentProfileIconVersion is higher than prefs::kProfileIconVersion when Chrome
starts or something (see my comment on ProfileShortcutManagerWin::Observe).

[Alexei Svitkine (slow), 2013/06/18 15:44:32]

See previous discussion. Having it an integer is more future proof, if we later
need to update existing icons for some reason (e.g. Chrome's icon changes)
rather than adding a whole new pref at that point.

[gab, 2013/06/18 15:51:38]

Right, makes sense, I think it's pretty easy to add such update code now though
(see my comment on ProfileShortcutManagerWin::Observe) which would prevent
somehow from assuming upping kCurrentProfileIconVersion is sufficient when it is
not.

+      user_prefs::PrefRegistrySyncable::UNSYNCABLE_PREF);
 #if defined(OS_CHROMEOS)
   // TODO(dilmah): For OS_CHROMEOS we maintain kApplicationLocale in both
   // local state and user's profile.  For other platforms we maintain