This implements support for hovering mouse pointers, so that mice connected to Android devices, and ChromeOS devices running Android apps will work properly.

It teaches flutter_test about hover events, which required changing how they are created and used.

Also modifies AnnotatedRegion to allow a region that can be located someplace other than just the origin.

Along with tests for all of the above.

Fixes #5504

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

Re-landing #23412 with a fix to the PlatformLayer's addToScene signature.

#23412 was broken by the change to Layer done in #23434.

It seemed green as the presubmits were done before #23434 was landed, and when #23412 landed it broke the build.

Reverts #23779

This reverts commit 67ffe1c2.

This PR adds the full framework stack (layer->render object->widget, and
service) for embedding iOS views with minimal functionality.

I allowed myself to throw the entire framework stack in one PR since we're mostly
mirroring the structure we already established for embedded Android views, so this PR
is a little bigger than usual. I'm happy to break it down to the
different pieces of the stack if reviewers prefer.

Specifically this PR adds:
* A UiKitView widget for embedding a UIView in the widget tree.
* A RenderUiKitView which is the render object for showing a
  UIView.
* A PlatformViewLayer which denotes the position of a UIView in the
  layer tree.
* The iOS platform_views system channel client code in services/platform_views.dart
* Splits the fake platform views controller to an Android and iOS
  controllers.

TBD in following PRs:
* Plumb the layout direction all the way to the platform view (currently
  there is still no engine support for it).
* Integrate with gesture arenas (engine support is still missing as
  well).

For #21756

For retained rendering, we don't want to push the offset down to each leaf layer. Otherwise, changing an offset layer on the very high level could cascade the change to too many leaves, which means that we can't retain them.

To not push the offset downwards, we simply push a TransformLayer when there's an offset. Skia has a fast path for concatenating scale/translation-only matrix so this operation should be fast (no performance regression is measured on Moto G4).

This is our first step towards https://github.com/flutter/flutter/issues/21756

In my local tests, this should finally fix https://github.com/flutter/flutter/issues/21617

* enable lint unnecessary_new

* fix tests

* fix tests

* fix tests

Revert "Revert "Enable taking screenshots of arbitrary RenderObjects from a running a… (#20637)" (#21395)" (#21448)

This reverts commit 5b5a5b82.

This reverts commit 3306fc10.

Enable taking screenshots of arbitrary RenderObjects from a running application from within the inspector.

Key functionality is in the added _ScreenshotPaintingContext class.

This reverts commit 8de0e15e and
updates the goldens versoin.

This requires https://github.com/flutter/flutter/pull/20751 to
land first.

This fixes https://github.com/flutter/flutter/issues/18057

Resizing an AndroidView happens asynchronously (as it requires thread
hopping from the ui thread to the platform thread).
While waiting for the resize to complete the framework does exactly when
the embedded view has been resized. This leads to pretty bad jank as the
framework might paint the embedded view with a wrong size.

We're working around this by freezing the texture frame while resizing
until we are sure that the next frame has the new size. This is how it
looks with the workaround:

This is how it looks before and after the workaround:

Before (janky) |  After (less janky)
:--------|---------:
![resize_before](https://user-images.githubusercontent.com/1024117/43669639-51bfd0ae-9739-11e8-8cbe-96e36f2460d2.gif) | ![resize_after](https://user-images.githubusercontent.com/1024117/43669647-62e885a6-9739-11e8-8aa4-beb74e979995.gif)

This depends on flutter/engine#5938. Additionaly right now the engine completes
the resize call immediately, a following PR will change it to complete
after a frame with the new size is ready.

See details in our proposal for this breaking API change and #18057. This PR setup all code paths to allow the change but doesn't change the clip behavior by itself. We'll change `defaultClipBehavior` from `Clip.antiAlias` to `Clip.none` in the following PR to change the clip behavior and update tests.

In theory, this should aid with tree shaking and minutely optimize the code in release builds.

It allows callers to account for things like shadows that paint
outside the bounds of the widget.

https://github.com/flutter/flutter/issues/16859

https://github.com/flutter/flutter/issues/16859

* pass shadowColor param to SceneBuilder

* add doc comment and diagnostic node for shadowColor

* Add missing shadowColor param

For backward compatibility we keep supporting specifying the shape as a
combination of MaterialType and borderRadius, and we just use that as a
default when shapeBorder is null.

To cleanup the implementation if shapeBorder was not specified we just
translate the specified shape to a shapeBorder internally.
I benchmarked paint, layout and hit testing, with the specialized shape
clippers vs. the equivalent path clippers and did not see any
significant performance difference.

For testing, I extended the clippers/physicalShape matchers to match either the
specialized shape or the equivalent shape.

This gets us back to where we were a few minutes ago.

This reverts commit 592f2979.

* Revive "Push physical layers with paths instead of rects in RenderPhysicalModel. (#13942)"

That commit was reverted due to a performance problem which has now been
fixed.

* Roll engine 05fe72d068e19c7886e8d27f9b004201d5ad1300

This reverts commit 57b4a525.