[macOS, multiwindow] Compositor gets FlutterView lazily

[dkwingsmt]

This PR changes macos/FlutterCompositor so that instead of getting FlutterViewController* at construction, it gets a callback that provides the FlutterView* lazily.

Part of the multiwindow project (design doc): This is a necessary step for multi-window because FlutterCompositor is constructed at engine initialization, while there can be multiple views or view controllers added after initialization.

Existing tests are adapted. No tests are added.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt. See testing the engine for instructions on
  writing and running engine tests.
• I updated/added relevant documentation (doc comments with ///).
• I signed the CLA.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[zanderso]

From PR triage: @dkwingsmt is this ready for another review pass from @stuartmorgan?

[dkwingsmt]

@zanderso @.stuartmorgan said he did not know enough to review this PR. Can you help me find someone to review it?

[iskakaushik]

I'm trying to understand how this would get used in the multi-window context, can you provide a brief sketch of how you would end up wiring the get view callback when there are multiple views at play?

[dkwingsmt]

Sure!

How will the compositor get view controllers in the future?

• The macos/FlutterEngine currently stores a single viewController, but in the future it will store a map of view controllers, which maps from surface IDs to view controllers (every view controller will have a unique ID).
• The view controller currently uses a fake ID 0 to call the callbacks, but in the future it will receive correct IDs.

Both changes (among others) are described in the design doc. It's still in progress, but contains sufficient information for this PR. https://docs.google.com/document/d/1U_ciMTHJgDrnw8kIo9sGKhiKFOycWRmz1yVVI_osCXg/edit

The core takeaway is that, in a multi-window world,

• A view controller corresponds to a view, therefore there will be multiple view controllers (and they can be added after the app starts).
• The Compositor class is a singleton.

Therefore the compositor must be able to handle additional views, instead of just the one from the constructor. It must either have a method of addViewController, or have a callback to get view controllers lazily.