Bug: fxb/79871

The code is still using the CFv1 implementation, so this should not affect the existing behavior.

For this version of the PR, I forked the existing DartComponentController. There were a few reasons for this:

Reduces the chance of the change breaking existing tests during Fuchsia GI.
Makes the V2 version of the DartComponentController simpler to read.
Makes it easier to switch over to using the V2 version of the DartComponentController once the migration is ready to happen (less cleanup).
The rate of changes to the DartComponentController is slow so there shouldn't be much maintenance required for the fork.
Changes to the DartRunner itself will happen in a follow-up PR - this PR only verifies that the ComponentController builds.

Relands GN and C++ changes for #27226 after rollback in #28036.

The multiprocessing package relies on the win32 `WaitForMultipleObjects`
call, which supports waiting on a maximum of MAXIMUM_WAIT_OBJECTS
(defined by Windows to be 64) handles, processes in this case.  To avoid
hitting this, we limit ourselves to 60 handles (since there are a couple
extra processes launched for the queue reader and thread wakeup reader).

When left unspecified, the multiprocessing module defaults this value to
os.cpu_count(), so this error is triggered only on machines with > 60
cores.

See: https://bugs.python.org/issue2690

Bug: https://github.com/flutter/flutter/issues/90085

* Don't assign overlays when overlays are disabled

* Add TODO for tests