Instrumenting WM_ message handler to find jank.

This is a follow-up for an internal discussion about possible jank, and more generally, performance issues that potentially are not tracked by about://profiler and UMA profiler data.

This CL adds instrumentation that adds tracking for all WM_ message handlers. It's enabled only in Canary, and on other channels we won't track WM_ messages.

If we find it valuable and safe, we can enable this instrumentation on other channels too.

BUG=440919

Review URL: https://codereview.chromium.org/793893002

Cr-Commit-Position: refs/heads/master@{#308001}

base/message_loop/message_pump_win.cc

@@ -10,6 +10,7 @@
 #include "base/message_loop/message_loop.h"
 #include "base/metrics/histogram.h"
 #include "base/process/memory.h"
+#include "base/profiler/scoped_tracker.h"
 #include "base/strings/stringprintf.h"
 #include "base/win/wrapped_window_proc.h"
 
@@ -319,6 +320,11 @@ void MessagePumpForUI::HandleTimerMessage() {
 }
 
 bool MessagePumpForUI::ProcessNextWindowsMessage() {
+  // TODO(vadimt): Remove ScopedTracker below once crbug.com/440919 is fixed.
+  tracked_objects::ScopedTracker tracking_profile(
+      FROM_HERE_WITH_EXPLICIT_FUNCTION(
+          "440919 <<MessagePumpForUI::ProcessNextWindowsMessage>>"));
+
   // If there are sent messages in the queue then PeekMessage internally
   // dispatches the message and returns false. We return true in this
   // case to ensure that the message loop peeks again instead of calling