Move Shell::Add/RemoveView to PlatformView and refine embedder API doc

[dkwingsmt]

This PR moves the methods to add or remove views from Shell to PlatformView. By design, the Shell is supposed to be a messenger that glues classes together, while PlatformView is the operator that embedders that do not use the embedder API should operate on. The current design was made due to lack of knowledge to this design.

This also makes PlatformView aware of views, which might be a prerequisite to #51925.

This PR also adds some details to embedder API AddView and RemoveView.

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 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.

[dkwingsmt]

@chinmaygarde Can you take a look? I'm not sure whether this is a necessary change. I'm proposing this only because I supposed the Shell should have as few methods as possible and the add/removeView methods should have existed on PlatformView to be consistent with other existing methods, such as DispatchPointerDataPacket.

[chinmaygarde]

Nit: Is this necessary? You can just use the typedef from the parent.

[dkwingsmt]

The compiler requires PlatformView::AddViewCallback (for both the methods in Delegate and Shell) instead of simply AddViewCallback without it, which is definitely not necessary though, and I'm down to remove it. What do you think?

[chinmaygarde]

What do the added and removed arguments to the callback mean? If added is false, why invoke the AddViewCallback? Perhaps document that?

[dkwingsmt]

Both the add and the remove callbacks rely on the result. For example, in the Windows embedder as implemented in #51923

• After calling AddView, the embedder blocks until a result is reported, which decides whether the returned FlutterWindowsView is null. (This eager blocking can be optimized in the future, but this is an easier approach for now.)
• The embedder also pre-allocate resources after calling AddView before the callback, and if the result turns out a failure, then the resources are deallocated. The pre-allocation ensures that the framework can start operating the view as soon as they're aware of it.
• After calling RemoveView, embedder does not deallocate resources until the callback (successful or not). This allows handling any pending operations during this time.

[dkwingsmt]

I kept the statement "The embedder should prepare resources in advance but be ready to clean up on failure." since I think this is a very useful implementation suggestion.

[loic-sharma]

LGTM, thanks for cleaning this up!