Initial addition of Blimp engine crash client code (take 2)

chrome/common/crash_keys.cc

Index: chrome/common/crash_keys.cc
diff --git a/chrome/common/crash_keys.cc b/chrome/common/crash_keys.cc
index 99efb58db472d237b54ade165d681d98d25ab950..d6c6fd07910548985e7574b2b772045e3022fc7c 100644
--- a/chrome/common/crash_keys.cc
+++ b/chrome/common/crash_keys.cc
@@ -88,6 +88,9 @@ const char kZeroEncodeDetails[] = "zero-encode-details";
 size_t RegisterChromeCrashKeys() {
   // The following keys may be chunked by the underlying crash logging system,
   // but ultimately constitute a single key-value pair.
+  //
+  // If you're adding keys here, please also add them to the list in

[Kevin M, 2016/05/02 22:05:32]

Maintaining two parallel key lists seems risky, and burdensome for contributors.

I recommend factoring out fixed_keys into a global array (kChromeCrashKeys?)
that we can reference and build off of in Blimp.

[Robert Sesek, 2016/05/02 22:07:00]

The CL description mentions a bug to fix this issue.

[marcinjb, 2016/05/03 18:06:58]

Yeah, I've got something going in http://crrev.com/1849413003, but that's going
to take some time finish and to land.  This CL is a way to get us crash
reporting sooner rather than later.

In parallel, the testing team is getting a buildbot to hopefully test some basic
interactions, so if someone introduces a breaking change, it'll get caught in
the CQ.

+  // //blimp/engine/app/blimp_engine_crash_keys.cc
   base::debug::CrashKey fixed_keys[] = {
 #if defined(OS_MACOSX) || defined(OS_WIN)
     { kMetricsClientId, kSmallSize },