Introduce async message queuing

Summary:
This diff introduces the logic for queueing incoming messages rather then directly processing them you are behind the `flipper_event_queue` GK.

The reason the queue processing is a bit complicated is to make the queue can be processed non-blocking, can be cancelled, and is safe to concurrency issues.
The idea here is that the queue is processed when we switch to a plugin, report it's progress, and abort the process when switching to another plugin without loosing any work.

This diff does not include
[x] updates to the UI (**SO DON"T LAND IN ISOLATION**)
[x] metrics to see the effect

The effect of the changes can be seen when profiling the application, before this change there are very regular CPU spikes (see the small yellow bar on the top):

https://pxl.cl/TQtl

These go away when the events are no longer processed
https://pxl.cl/TQtp

Reviewed By: nikoant

Differential Revision: D19095564

fbshipit-source-id: 0b8c3421acc4a4f240bf2aab5c1743132f69aa6e

src/utils/__tests__/Idler.node.js

@@ -18,6 +18,7 @@ test('Idler should interrupt', async () => {
       if (i == 100) {
         expect(idler.shouldIdle()).toBe(false);
         idler.cancel();
+        expect(idler.isCancelled()).toBe(true);
         expect(idler.shouldIdle()).toBe(true);
       }
       await idler.idle();
@@ -57,7 +58,9 @@ test('TestIdler can be controlled', async () => {
   idler.idle();
   await idler.next();
 
+  expect(idler.isCancelled()).toBe(false);
   idler.cancel();
+  expect(idler.isCancelled()).toBe(true);
   expect(idler.shouldIdle()).toBe(true);
 
   let threw = false;