* Use hint freed specifically for image disposal

* Log exception in addition to the stack trace for unhandled exceptions.

Having exception logged can be especially useful when stack trace is blank.

* Clear the GL context only after submitting the frame
* Fix Screenshot test

This reverts commit 95f2b727.

This reverts commit 58a62076.

* `Image.toByteData()` was not implemented in either DomCanvas or CanvasKit. This PR covers **both.**
* `Picture.toImage()` was not implemented in either DomCanvas or CanvasKit. This PR covers **CanvasKit**

## Description
As the related issue refer, the application may be doing too much work on its main thread even in a simple hello_world demo.
That is because the creation of `Engine` on the ui thread takes a noticeable time, and it is blocking the platform thread in order to run `Shell::Setup` synchronously.
The cost of `Engine`'s constructor is mainly about the creating of root isolate. Actually, there used to be another time-consuming process, the default font manager setup, which was resolved by https://github.com/flutter/engine/pull/18225. 
Similar to https://github.com/flutter/engine/pull/18225, this pr move the creation of root isolate out from creating `Engine`. After this action, the main thread blocking is quite an acceptable slice.

## Related Issues
https://github.com/flutter/flutter/issues/40563 could be resolved by this pr.

The C++ wrapper makes heavy use of templates to support arbitrary types
in the platform channel classes, but in practice EncodableValue is what
essentially all code will use. This defaults those template types to
reduce boilerplate in plugin code (e.g., allowing the use of
MethodChannel<> instead of MethodChannel<EncodableValue>).

https://dart.googlesource.com/sdk.git/+log/6eab35f49cbb..2a5f37d25453

2020-09-01 dart-luci-ci-builder@dart-ci.iam.gserviceaccount.com Version 2.10.0-80.0.dev

If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/dart-sdk-flutter-engine
Please CC dart-vm-team@google.com on the revert to ensure that a human
is aware of the problem.

To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/master/autoroll/README.md

* migrate from e2e to integration_test

* address reviewer comments

If the InputConnectionAdaptor receives a key event that does not move
the caret or produce a text character (such as the back button), then
the event should be given to the EventResponder which will forward it
to the view.

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

The embedding was only handling vertical scroll events from the OS; this
adds horizontal as well.

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

This reverts commit 4de62c7c.

Reduces errors caused by the loss of floating point precision when the
two extrema of the lerp differ significantly in magnitude. Previously,
we used the calculation:

    a + (b - a) * t

When the difference in magnitude between `a` and `b` exceeds the
precision representable by double-precision floating point math, `b - a`
results in the larger-magnitude value of `a` or `b`. The error between
the value produced and the correct value is then scaled by t.

A simple example of the impact can be seen when `a` is significantly
larger in magnitude than `b`. In that case, `b - a` results in `a` and
when `t` is 1.0, the resulting value is `a - (a) * 1.0 == 0`.

The patch transforms the computation to the mathematically-equivalent
expression:

    a * (1.0 - t) + b * t

By scaling each value independently, the behaviour is more accurate.
From the point of view of performance, this adds an extra
multiplication, but multiplication is relatively cheap and the behaviour
is significantly better.

This patch also adds a `precisionErrorTolerance` constant to
test_utils.dart and migrates existing tests to use `closeTo()` for
testing.

The tests themselves *do* currently use values that have an exact
floating-point representation, but we should allow for flexibility in
future implementation changes.