Breaking change: removed facilities for JSON and string messaging from FlutterView/FlutterViewController, leaving only binary messaging there. All other use of flutter communication now goes through FlutterMessageChannel and FlutterMethodChannels. Retained use of String and JSON codecs for now.

Companion flutter PR: flutter/flutter#8837

Flutter channels now also supported on iOS. Use FlutterMessageChannel or FlutterMethodChannel with binary/string/json/standard codecs.

This change eliminates two previous assumptions:
1. If a Flutter view is embedded in a parent view, that the parent view
   controller would apply any status bar padding necessary.
2. That we should not apply padding unless the flutter view is
   fullscreen.

A simple case where the first assumption fails to hold is a Flutter view
embedded in a UINavigationController with a hidden toolbar. A simple
case where the second assumption fails to hold is a view in a window
whose top overlaps the status bar but isn't fullscreen.

* [iOS] Ensure FlutterMain is called before interacting with the engine in any way.

* Licenses

On iOS, when a tap is detected in the status bar, provide a means to
pass that touch event through to one or more FlutterViewControllers to
trigger a scroll to top. In iOS apps, scroll to top should occur under
the following conditions:

1. There is one and only one UIScrollView visible with
   scrollsToTop == YES.
2. The status-bar is in standard height mode, not in double-height mode.
   In double-height mode, the expected behaviour is to trigger a switch
   to the application associated with the double-height status bar.
3. A tap or a drag gesture occurs that is entirely constrained to the
   status bar frame. (We currently only handle the tap scenario).

Unfortunately, AppDelegates only get touchesBegan events for status bar
taps, though get get touchesBegan and touchesEnded events for drags
within the status bar frame. As such, we currently synthesise the
touchesEnded event for taps.

* Apply iOS status bar padding only to fullscreen views

Previously padding was applied to account for the status bar, whether in
standard or expanded 'in-call' geometry only if the current view was not
a subview of a containing view. This didn't cover the case of root views
embedded in other windows (e.g. dialogs).

We also ensure that the window is fullscreen to account for cases like
small dialogs centred on the screen.

* Do not apply padding if we're a subview in a containing view

* Handle double-height status bar on iOS

In certain cases, iOS displays a double-height status bar (e.g., when an
application is using device location or while in a call). In such cases,
iOS offsets the app view origin by 20px, reduces view height by 20px,
then overlays a 40px opaque status bar: 20px covering the newly opened
20px gap at the top of the screen, 20px covering the top 20px of the
view, which had previously been under the standard-sized status bar.

Flutter previously set top padding to the height of the status bar,
which resulted in 40px padding with a double-sized status bar. However,
the padding should match the portion of the status bar overlapping the
view, which is 20px.

Note that the final case is the one in which no status bar is shown and
padding should be zero.

* Only apply status bar padding on root views

These are implemented on macOS and Fuchsia.

We no longer use mojom to transport messages. We still use the Mojo EDK
to spin the event loop, however.

Now we just pass the data directly.

Previously, these signals were sent over Mojo. Now we send them through
platform messages.

This patch removes the use of the host messages mojom and switch all
message routing over to platform messages.

Previously we had a mix of the two.

Previously we were rounding event time stamps to the nearest second
because ftl::TimeDelta::FromSeconds takes an integer number of seconds.
Now we just convert directly from floating point seconds to
microseconds to avoid losing precision.

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

The platform use cases are handled by the PlatformPlugin. The media service and
the sensor service have no clients. If we want to use them, we should create
plugins for them.

Also, expose a convenience class for processing JSON messages.

This fixes this Fuchsia build, which uses the latest //lib/ftl.

This patch moves the rest of the clients to use the new PointerData
transport.

* Namespaces have been updated to reflect the move from //flutter/sky/shell to //flutter/shell.
* shell/BUILD.gn file has been split into smaller GN files for each subcomponent of the shell (common, GPU, diagnostic, testing).
* GN dependencies have been rewritten to stop exposing common shell dependencies as public. Duplicates have also been removed.
* GPU subcomponent has been updated make it more suitable for Vulkan integration.
* The GLFW backend has been resurrected.

Replicates iOS behavior of placing trace files in the documents directory.

This patch hides the base::SingleThreadedTaskRunner, which pulls a big
switchover to ftl::WeakPtr and std::function.

Remove dependencies on ui, third_party/mesa and mojo/convertors. Provide simple alternatives. (#2783)