macOS: Disable AppNap for browser process.

Renderers never go to sleep. If the browser goes to sleep, IPC messages will
queue up. When the browser finally wakes up, it can stall for 30min+ processing
those IPC messages. This CL disables AppNap for the browser process, which will
make sure that IPC messages get processed in a timely fashion.

This CL does not set the Info.plist option NSSupportsAppNap to false, as that
has no effect.

To test:
1) Run
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister
-f <path_to_chrome> if changing the Info.plist.
2) Launch Chrome from the finder.
3) Switch to a different virtual desktop [no chrome windows showing].
4) Launch Activity Monitor, switch to "energy" view, make sure Chrome/Chromium
is visible.
5) Launch Safari and make sure it's the active app.
6) Wait 10 minutes

Expected results:
Chrome/Chromium does not enter AppNap.

Previous results:
Chrome/Chromium does enter AppNap.

Bug: 871235
Change-Id: I9af05e38b7706c9e61a99316a88fd4ea5fada997
Reviewed-on: https://chromium-review.googlesource.com/1163726Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#580925}

services/service_manager/embedder/mac_init.mm

@@ -19,6 +19,12 @@ void InitializeMac() {
     // application:openFile:], because they are handled directly. @"NO" looks
     // like a mistake, but the value really is supposed to be a string.
     @"NSTreatUnknownArgumentsAsOpen" : @"NO",
+
+    // Don't allow the browser process to enter AppNap. Doing so will result in
+    // large number of queued IPCs from renderers, potentially so many that
+    // Chrome is unusable for a long period after returning from sleep.
+    // https://crbug.com/871235.
+    @"NSAppSleepDisabled" : @YES,
   }];
 }