Auto-roller completed checks. Merging.

Auto-roller completed checks. Merging.

Auto-roller completed checks. Merging.

Auto-roller completed checks. Merging.

Auto-roller completed checks. Merging.

Auto-roller completed checks. Merging.

Auto-roller completed checks. Merging.

Auto-roller completed checks. Merging.

Reverts flutter/engine#5740

So we'll no longer need #5734 and #5708

Each platform view created (by a plugin supplied factory) is attached to
a virtual display.
The virtual displays are controlled by VirtualDisplayController objects.
The PlatformViewsController maintains a mapping from a platform view's
id to its VirtualDisplayController, which allows it to operate on the
virtual display for a given platform view ID when asked so over the
method channel.

This is using API level 20 APIs, on lower API levels all platform views
method channel calls are noops.
We can make this work on API 19 with some refactoring to the
TextureRegistry (allow the engine Java code to recycle a texture entry
id).

This CL also adds a platform view id parameter to the
PlatformViewFactory#create() method. This allows plugins to route
platform channel messages to specific instances of a platform view.

TBD in future CLs:
  * Forward touch events to the platform views.
  * Support accessibility for platform views.

flutter/flutter#19030

For flutter/flutter#18057

Auto-roller completed checks. Merging.

Auto-roller completed checks. Merging.

Auto-roller completed checks. Merging.

Auto-roller completed checks. Merging.

Auto-roller completed checks. Merging.

Auto-roller completed checks. Merging.

Auto-roller completed checks. Merging.

Auto-roller completed checks. Merging.

Auto-roller completed checks. Merging.

To keep the scope of this CL as small of possible I'm leaving the actual
implementation of the platform view mechanics to a following CL.

This CL introduces:
  * A PlatformViewsController class which will be responsible for creating,
    resizing, and disposing platform views.
  * A PlatformViewRegistry which is exposed through the PluginRegistry
    and allows plugins to register factories for platform views.

Android plugin code will add support for a new platform view type by
implementing PlatformViewFactory, and registering a factory with the
registry, e.g:
```java
registrar.platformViewRegistry().registerViewFactory(
  'webview',
  new FlutterWebViewFactory()
);
```
On the Dart side, the framework will ask the engine to create new
platform views by sending a create message over the platformviews method
channel with the unique platform view type id, dimensions, and a unique
id allocated by the framework for the new platform view instance.
The platformviews method channel is also used for resizing and disposing
platform views.

Auto-roller completed checks. Merging.

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

Auto-roller completed checks. Merging.

Auto-roller completed checks. Merging.

Auto-roller completed checks. Merging.

Auto-roller completed checks. Merging.

Auto-roller completed checks. Merging.