Handle RenderProcessHostImpl::SetBackgrounded on Windows

Handle RenderProcessHostImpl::SetBackgrounded on Windows

This was disabled on Windows because:

 - http://crrev.com/274071 made it such that it was asynchronous via the renderer (as only
the process itself can set itself in background mode on Windows).

 - And then this was removed for Windows as part of issue 381820 as true background mode on
Windows was achieved by having the renderer itself change its process priority (which
doesn't work as the unbackgrounding request can be stuck behind other priority tasks
running in background mode).

Also, the test for this was disabled in between (see issue 394368) -- the asynchronicity
introduced in r274071 probably causing the flakes.

Overall there is no need to have the renderer enter PROCESS_MODE_BACKGROUND_BEGIN itself,
IDLE_PRIORITY_CLASS should be sufficient as its the same as far as CPU priority is
concerned and IO is irrelevant in the renderers.

Thus we can get background mode for hidden renderers without running into issue 381820.

Experiment with IDLE_PRIORITY_CLASS/BELOW_NORMAL_PRIORITY_CLASS vs the status quo.

Watching the relevant perf bots (tab_switching.top_10 -> MPArch.RWH_TabSwitchPaintDuration)
and UMA metrics MPArch.RWH_TabSwitchPaintDuration which shouldn't regress.
And others (e.g., SessionRestore related) which will hopefully improve.

Enable the experiment by default in the absence of Finch to get perf waterfall coverage.

The experiment will be called "BackgroundRendererProcesses" and have 4 groups:
 ["Disallow", "AllowBelowNormalFromBrowser",
  "AllowIdleFromBrowser", "AllowBackgroundModeFromRenderer"]

It will be a per-session (rather than per-profile) experiment, randomly assigning a user
to a group every new Chrome session.

BUG=394368, 458594

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

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