This reverts commit 735876ed.

We now have one mutex guarding all accesses to
the underlying task heaps. This simplifies the more granular
but bug prone mechanism of having striped locks.

This also re-enables GPUThreadMerger tests that are currently
disabled due to their flaky nature. The scenario that gets fixed by this
change is as follows:

1. Thread-1: We lock `queue_meta_mutex_` and grab locks on `queue_1` and release the meta mutex.
2. Thread-1: We add an Observer on `queues` object.
3. Thread-2: We lock `queue_meta_mutex_` and grab locks on `queue_2`.
4. Thread-2: We try to dispose all the pending tasks on `queue_2` which calls `erase` on `queues`.

The above situation is not thread safe without having 1 lock.

Note: This increases the contention on one lock and could potentially be bad for perf. We are
explicitly making this trade-off towards reducing the complexity.

Fixes: https://github.com/flutter/flutter/issues/49007

Moved our code to passing functions by const ref

Fixes https://github.com/flutter/flutter/issues/42704.

The core underlying issue is that vector push_back could re-allocate and cause us to segfault. I have switched the backing queues to a map per @jason-simmons suggestion in flutter/flutter#38778.

I've also added a test to capture the aforementioned bug. I've run internal tests several times to validate that this is fixed.

General threading note for this class is that only the following operations take a write lock on the meta mutex:

1. Create
2. Dispose

The rest of the operations take read lock on the meta mutex and acquire finer grained locks for the duration of the operation. We can not grab read lock for the entire duration of NotifyObservers for example because observer can in-turn create other queues -- Which we should not block.

Additional changes:

1. Make as many methods as possible const. Unlocked methods are all const.
2. Migrate all the queue members to a struct, and have a map.
3. Get rid of the un-used Swap functionality.

- Add the functionality to merge and unmerge MessageLoopTaskQueues

This introduces a notion of a "owning" and "subsumed" queue ids.
Owning queue will take care of the tasks submitted to both that and it's
subsumed queue.

- The tasks submitted still maintain the queue affinity
- Same for the task observers

- Also adds MergedQueuesRunner which grabs both the locks owner
  and subsumed queues in RAII fashion.

- Also use task queue id to verify if we are running
  in the same thread.

- This is to enable merging the backed message loop task
  queues to enable dynamic thread merging in IOS.