This reverts commit 7932ba76.

The Android and iOS versions of this function had diverged. This patch
makes the iOS version match the Android version (and what the framework
expects).

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

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

* Perform all iOS logging through ASL

As of iOS 10, ASL is deprecated and replaced with os_log. ASL calls
continue to result in logging but as of iOS 10.3, only ASL_LOG_NOTICE
level and above are logged.

This change partially reverts 2937f06a,
adding back stdout and stderr redirection, which resulted in loss of
some direct writes to stdout that were necessary for debugging.

This change replaces the direct use of syslog with ASL on iOS, which
Apple has stated will continue to log on iOS >= 10. This eliminates the
need for the previous fwd-declaration of syslog.

ASL is deprecated and replaced by os_log() on iOS. As of iOS 10.3,
calling this function breaks our logging altogether. os_log isn't
available pre-iOS 10.0. Rather than implement version checks and
conditional logic, this change eliminates the existing redirection
altogether. All engine code should be logging via the syslog redirection
implemented in Logger_PrintString in dart_runtime_hooks.cc.

Since stdio redirection is eliminated, we eliminate the flag that
controls whether such redirection is enabled.

See https://github.com/flutter/flutter/issues/7561

Names matter, and I apparently forgot to test after adding ' Engine' to
the name. Names can't contain spaces, and must match the filename.

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

* Add podspec to Flutter iOS framework.

Flutter iOS apps are already pod-enabled, so we might as well turn the
engine framework into a pod, so we don't have to manually copy the
current Flutter.framework into the app directory on every build, but
rather let Cocoapods wire things up for us.

For that to happen, we need a pod spec for Flutter.framework. This spec
will not be published, but rather downloaded as part of the engine
artifacts, and the app's Podfile will have a local path dependency on
it.

* Update licenses_golden...

New concepts: FlutterMessageChannel (basic message send/receive superseding existing FlutterView methods), FlutterMethodChannel (method invocation and event streams), pluggable codecs for messages and method calls: unencoded binary, string, json, and 'standard' flutter binary encoding.

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

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.

I had added this initially as a means of making it easier to deal with OpenGL directly in Flow. However, we are moving away from dealing with the client rendering APIs directly. Instead, delegating everything to Skia. Besides, we only ever used this to log the GPU description in case of context setup failures. This has not proved to be useful so far. Also, having this in place is making it difficult to remove all dependencies on GL in Shell.

Ensure that the text input keyboard is reloaded if the view keyboardType
changes.

Added:
* UIRequiredDeviceCapabilities=[arm64]
* MinimumOSVersion=8.0

Provide a default status bar tap handler for FlutterAppDelegate.
By default, taps are passed to the key window's rootViewController if
it's a FlutterViewController. Apps with custom app delegates can
customize this behaviour to send the tap to the FlutterViewController(s)
they prefer by overriding touchesBegan:withEvent.

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

* Licenses

The PlatformView superclass constructor was posting a task to the UI thread
that adds the view to the shell's global list.  This could result in UI thread
operations seeing PlatformView instances that are not fully constructed and do
not yet have an engine.

This was happening in https://github.com/flutter/flutter/issues/7735