Add metrics to keep track of the tab activate/deactivate cycle

chrome/browser/metrics/chrome_browser_main_extra_parts_metrics.cc

Index: chrome/browser/metrics/chrome_browser_main_extra_parts_metrics.cc
diff --git a/chrome/browser/metrics/chrome_browser_main_extra_parts_metrics.cc b/chrome/browser/metrics/chrome_browser_main_extra_parts_metrics.cc
index 278f2ecd87f8af1b1e1ec0ec945135262a430320..5a5b9a70664c5f6b958aaa9e5117491652c6c51e 100644
--- a/chrome/browser/metrics/chrome_browser_main_extra_parts_metrics.cc
+++ b/chrome/browser/metrics/chrome_browser_main_extra_parts_metrics.cc
@@ -20,6 +20,7 @@
 #include "chrome/browser/browser_process.h"
 #include "chrome/browser/chrome_browser_main.h"
 #include "chrome/browser/mac/bluetooth_utility.h"
+#include "chrome/browser/metrics/tab_usage_recorder.h"
 #include "chrome/browser/shell_integration.h"
 #include "components/flags_ui/pref_service_flags_storage.h"
 #include "content/public/browser/browser_thread.h"
@@ -370,6 +371,8 @@ void ChromeBrowserMainExtraPartsMetrics::PostBrowserStart() {
 #if !defined(OS_ANDROID)
   FirstWebContentsProfiler::Start();
 #endif  // !defined(OS_ANDROID)
+
+  metrics::TabUsageRecorder::Initialize();

[Georges Khalil, 2016/09/16 18:58:35]

I think this should be in an experiment. I'm concerned about a potential
regression on tab switch time, so having an experiment will give us much better
control.

[Patrick Monette, 2016/09/19 17:47:12]

IMO This is amount of prudence is too much. TabUsageRecorder does very little
work and there is no reasons it should have an impact on tab switch time. But if
you feel strongly about this concern, I'll add the experiment.

 }
 
 void ChromeBrowserMainExtraPartsMetrics::OnDisplayAdded(