This moves the Metal `GrContext` creation utilities from `GPUSurfaceMetal` into
a separate `IOSContext` object subclass. An analogue of this object was used in
the GL regime for the management of onscreen and offscreen contexts that were
not tied to the lifecycle of the `GPUSurface`. This pattern has now been
generalized for use with all backends that need a resource context
(`IOSContextGL` and `IOContextMetal`).

The platform views controller management in the `ExternalViewEmbedder` interface
implementation was repeated three times for [Metal][metal], [OpenGL](opengl) and
[Software](software) rendering. This repetition has been removed and a single
implementation present in the base `IOSSurface` and used on all platforms.
Addition of new client rendering APIs should not affect how the engine renders
into the platform view interleaving levels.

All rendering API selection logic has been moved into a single set of utilities
in `rendering_api_selection.h`. This enables the removal of a lot of code blocks
guarded by `FLUTTER_SHELL_ENABLE_METAL`. The remaining uses of this will be
removed when unified builds are enabled.

The Metal backend now also adds traces similar to the GL backend.

The `IOGLContext` has been renamed to `IOContextGL` to be more in line with the
convention used in this library.

Fixes https://github.com/flutter/flutter/issues/41827
Adds https://github.com/flutter/flutter/issues/52150

[metal]: https://github.com/flutter/engine/blob/1194ba2b218706a201c5d2c5325b55a5932546c5/shell/platform/darwin/ios/ios_surface_metal.mm#L55
[opengl]: https://github.com/flutter/engine/blob/1194ba2b218706a201c5d2c5325b55a5932546c5/shell/platform/darwin/ios/ios_surface_gl.mm#L95
[software]: https://github.com/flutter/engine/blob/1194ba2b218706a201c5d2c5325b55a5932546c5/shell/platform/darwin/ios/ios_surface_software.mm#L146

This was only necessary when the Engine had to build in multiple buildroots
where the sources where checked out at different paths relative to the
buildroot. This is no longer the case and there are already cases GN rules
have been written that mix and match variable usage with the direct
specification of the path to the Flutter sources relative to the sole buildroot.

This reverts commit f456423c.

This is being reverted because it caused flutter/flutter#45098
(images don't load on iOS).

This reverts commit 2dcfaaeb.

This reverts commit 618e6666.

Revert "Always use `IOSGLContextSwitch` to access EAGLContexts to prevent plugins from polluting Flutter's EAGLContext (#13314)" (#13753)

Always use `IOSGLContextSwitch` to access EAGLContexts to prevent plugins from polluting Flutter's EAGLContext (#13314)

change_install_name.py was operating on framework library files
in-place, which breaks GN's timestamp analysis handling since a file
can't be both an input and output of an action. As a result no-op builds
on macOS were not actually no-ops.

This changes the script to operate on an output copy, both fixing the
no-op build issue, and simplifying the GN framework construction scripts
by combining the copy step and the install-name step.

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

Declare a copy of the enable_bitcode flag within the Flutter build scripts for use in Fuchsia builds (#10003)

enable_bitcode is defined in build/toolchain/clang.gni, which exists in the
Flutter buildroot but not in the Fuchsia source tree.

Started adding the engine hash to Flutter.framework's Info.plist.

Made the engine and the view controllers have BinaryMessengers, not be
BinaryMessengers.  This allows us to break retain cycles and makes the
leaking channels we have not less dire.

When the macOS framework was initially landed, it included some iOS code
using a localized hack. This reorganizes the code structure to clearly
indicate which files are shared between iOS and macOS, vs. those that
are platform-specific.

Cleanup repeated rules.

Moved the frame buffer specific logic from IOSGLContext to IOSGLRenderTarget.

use recording canvases for overlays

Support platform view overlays with gl rendering.

This also changes the overlay canvases (for both software and gl
rendering) be recording canvases, and only rasterize them after
finishing the paint traversal.

The overlay surfaces are going to be the same IOSSurface implementation
with the platform views controller set to null (so these are surfaces
that don't support embedding platform views to them).

  * Adds a FlutterOverlayView which is a UIView that's showing an
    overlay surface.
  * Creates an overlay surface for each embedded UIView (done in
    FlutterPlatformViewsController).
  * Changes CompositeEmbeddedView to return a new canvas.
  * Makes the PlatformViewLayer replace the PaintContext's canvas with
    the canvas for the overlay view.
  * Changed canvas in PaintContext to be a pointer so it can be changed.

TBD in following PRs:
  * Copy the current canvas state when replacing a canvas in PaintContext.
  * Make FlutterOverlayView work with a GL backend (currently it only
    works with software rendering)

* Create FlutterEngine to manage a Shell to support maintaining execution state across instances of FlutterViewControllers
* Refactor PlatformViewIOS to support adding or removing a FlutterViewController dynamically
* Refactor FlutterDartHeadlessCodeRunner to implement FlutterEngine
* Refactor FlutterViewController to accept a FlutterEngine at initialization or to create one for backwards compatibility; any Shell related responsibilities are now passed through to the Engine instance
* Remove FlutterNavigationController (unused)
* Update all public Objective C doc comments to be consistent and formatable
* Add public documentation to all public headers

Adds a FlutterPlatformViewFactory protocol - a simple factory protocol to be implemented by plugins
  that exposes a UIView for embedding in Flutter apps.
* Adds a FlutterPlatformView protocol, which is used to associate a
  dispose callback with a `UIView` created by a FlutterPlatformViewFactory.
* Exposes a registerViewFactory method in FlutterPluginRegistrar.
* Implements the `flutter/platform_views` system channel on iOS, allowing
  Dart code to ask for creation/destruction of UIViews.

* Publish port of observatory over mDNS

Remove touch mapper and respect the UITouch phase when calculating the pointer data change type. (#6430)

The touch mapper was a relic of a time when the pointer IDs had to be less
than 16. Not respecting the touch phase is getting in the way of clients that
fake their own touches. Turns out the AppDelegate also like to fake touches to
simulate status bar events. Now, except in cases where there is a specific
override in place, the UI touch phase is respected.

* Updated DartCallbackCache to write callback cache to disk which is
restored on engine startup
* Ensure cache isn't moved off disk in iOS