Ensure that the DirectWrite font cache works in Chrome canary on Windows 8+ with...

Ensure that the DirectWrite font cache works in Chrome canary on Windows 8+ with AppContainer protection.

The DirectWrite font cache is mapped as a shared section by the renderer processes. The browser creates
the section. On Windows 8+ with AppContainer protection the renderers are unable to open this shared section
as the BaseNamedObjects object directory is virtualized to \Sessions\SessionId\AppContainerNamedObjects.

This effectively means that the renderers now fallback to the old method of enumerating all fonts while DirectWrite
builds up its font cache. This hurts performance.

Proposed fix is as below :-
1. When the renderer process is launched we get notified in the RenderProcessHost::OnProcessLaunched method.
   We send a control IPC message here ViewMsg_FontCacheSectionHandle which contains the duplicated font cache
   section handle.

2. The ViewMsg_FontCacheSectionHandle message is handled by RenderThreadImpl. It ensures that the shared handle
   is set by calling a helper function SetFontCacheSectionHandle. This function then triggers the setting of the
   DirectWrite font factory in skia.

3. Some of the code in the WarmupDirectWrite function is no longer needed like the code to create the font factory
   and create some fonts to warm up DirectWrite. This is because DirectWrite in the renderer now uses the custom
   font collection which means that most of the code now can run in the sandbox. The only parts which need to run
   outside the sandbox are the loading of the dwrite.dll and the code in the FontCollectionLoader which reads fonts
   from the registry.

4. The GetPreSandboxWarmupFontMgr helper function has been renamed to GetDirectWriteFontManager.

The UMA metric DirectWrite.Fonts.LoadTime.Cached should be available if the font cache is loaded in the renderer.

BUG=481285
R=cpu

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

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