* Revert "Fix documentation build for window changes. (#21780)"

This reverts commit 931a0468.

* Revert "Migration to PlatformDispatcher and multi-window (#20496)"

This reverts commit 85b0031f.

This reverts commit 5585ed99.

Additionally, the following _flutter.runInView deadlock is fixed.

Previously, a deadlock would occur when service protocol
_flutter.runInView is used to restart the engine wihtout tearing down
the shell: the shared mutex of the service protocol will be locked
during the restart as it's in the middle of handling a service protocol
message; if ServiceProtocol::AddHandler is also called during the
restart, the deadlock happens as AddHandler also requires such lock.

test/integration.shard/background_isolate_test.dart would fail
without this fix.

This is a PR for converting the dart:ui code in the engine to use a multi-window API. The goal here is to convert from the window singleton to an API that has the concept of multiple windows. Also, I'm matching up the new PlatformDispatcher class to talk directly to the PlatformConfiguration class in the engine. I'm not attempting to actually enable creating multiple windows here, just migrate to an API that has a concept of multiple windows. The multi-window API in this PR currently only ever creates one window.

The design doc for this change is here.

The major changes in this PR:

Move the platfom-specific attributes out of Window, and into the new PlatformDispatcher class that holds all of the platform state, so that the platform code need only update the configuration on this class.
Create FlutterView, FlutterWindow, and SingletonFlutterWindow classes to separate out the concepts of a view (of which there may be multiple in a window), a window (of which there may be multiple on a screen, and they host views), and a window where there is only ever expected to be one (this hosts the entire API of the former Window class, and will eventually be the type of the window singleton).
Next step after this PR lands:

Remove the Window class entirely (it is replaced by SingletonFlutterWindow). Some minor changes in the Framework are needed to switch to using SingletonFlutterWindow directly first.

The Window class still exists in this PR, but will be removed as soon as the framework is converted to point to the SingletonFlutterWindow class instead. They share the same API, just have different names (Window is currently a subclass of SingletonFlutterWindow). The intention is that the Window name will be freed up to use as a widget class name in the framework for managing windows. The singleton called window will remain, and keep the same API it has now.

Preserve specified AssetResolvers when performing a hot restart or updating the asset directory (#21611)

Follow up from #21436 . That PR works for all embeddings except for Android, which creates a special JNI AssetResolver. Since the shell cannot recreate this resolver, update the logic to preserve existing resolvers instead.

Otherwise, the persistent cache may hold invalid directories and make
subsequent store fail.

The newly added unit tests would fail without the fix.

Always add the asset resolver from the configuration settings directory when restarting or recreating the asset manager

This reverts commits
- 67fdd7ed.
- 854943d5.

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

Embedders can now notify shell during startup about the various displays and their corresponding settings.
Adds a notion of Display update type which can later include chages to displays during runtime such as addition / removal / reconfiguration of displays.

We also remove the responsibility of providing the refresh rate from `vsync_waiter` to `DisplayManager`.
Rewires existing platform implementations of the said API to use `Shell::OnDisplayUpdate` to notify the display manager of the startup configuration.

DisplayManager is also thread-safe to account for rasterizer and UI thread accesses.

* Avoid sending a 0 DPR to framework

* check width and height as well

This will allow customers to try out the lightweight isolate support in the Dart VM in AOT mode.

To be future proof, we also add the negative flags to the allow list, thereby allowing the Dart VM to
change the default in the future, while still allowing customers to opt out.

Issue b/158554251

Cleans up header order/grouping for consistency: associated header, C/C++ system/standard library headers, library headers, platform-specific #includes.

Adds <cstring> where strlen, memcpy are being used: there are a bunch of places we use them transitively.

Applies linter-required cleanups. Disables linter on one file due to included RapidJson header. See https://github.com/flutter/flutter/issues/65676

This patch does not cover flutter/shell/platform/darwin. There's a separate, slightly more intensive cleanup for those in progress.

We currently use a mix of C standard includes (e.g. limits.h) and their
C++ variants (e.g. climits). This migrates to a consistent style for all
cases where the C++ variants are acceptable, but leaves the C
equivalents in place where they are required, such as in the embedder
API and other headers that may be used from C.

The directory may be invalid when running shell_unittests because
some tests call SetCacheDirectoryPath and then delete the directory.
Later tests that try to use that cache base path will be unable to
open the directory.

Add copyright headers in a few files where they were missing.

Trim trailing blank comment line where present, for consistency with
other engine code.

Use the standard libtxt copyright header in one file where it differed
(extra (C) and comma compared to other files in libtxt).

This also amends tools/const_finder/test/const_finder_test.dart to look
for a const an additional four lines down to account for the copyright
header added to the test fixture.

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

The following devicelab tests should pass after this patch:

- flutter_gallery_sksl_warmup__transition_perf_e2e_ios32
- flutter_gallery_sksl_warmup_ios32__transition_perf

This reverts commit 575a5194.

Lazy async stacks were already enabled by-default in AOT mode in [0] - which made the
gen_snapshot invocations use "--lazy-async-stacks --no-causal-async-stacks".

This change does the same with the engine defaults, which makes this be enabled
by-default in JIT mode as well.

See go/dart-10x-faster-async for more information.

This is a re-land: A fix for what we believe to have caused the last revert has landed upstream in Dart in dart-lang/sdk@0004589

[0] flutter/flutter@3478232

This test has been flaky on LUCI recently.

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

* Use hint freed specifically for image disposal

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

This reverts commit 95f2b727.

## 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.