* Windows: Add CoreWindow implementation of FlutterWindowsView (Flutter#70205)

The current text input manager is win32-specific due to its use of
IMM32. For UWP, we'll need a TSF implementation. Once that happens we'll
want to extract out a TextInputManager interface and add a separate UWP
implementation of this class.

This updates the Win32 desktop embedder to support input method (abbreviated IM
or IME) composing regions.

In contrast to languages such as English, where keyboard input is
managed keystroke-by-keystroke, languages such as Japanese require a
multi-step input process wherein the user begins a composing sequence,
during which point their keystrokes are captured by a system input
method and converted into a text sequence. During composing, the user is
able to edit the composing range and manage the conversion from keyboard
input to text before eventually committing the text to the underlying
text input field.

To illustrate this, in Japanese, this sequence might look something like
the following:

1. User types 'k'. The character 'k' is added to the composing region.
   Typically, the text 'k' will be inserted inline into the underlying
   text field but the composing range will be highlighted in some manner,
   frequently with a highlight or underline.
2. User types 'a'. The composing range is replaced with the phonetic
   kana character 'か' (ka). The composing range continues to be
   highlighted.
3. User types 'k'. The character 'k' is appended to the composing
   range such that the highlighted text is now 'かｋ'
4. User types 'u'. The trailing 'k' is replaced with the phonetic kana
   character 'く' (ku) such that the composing range now reads 'かく'
   The composing range continues to be highlighted.
5. The user presses the space bar to convert the kana characters to
   kanji. The composing range is replaced with '書く' (kaku: to write).
6. The user presses the space bar again to show other conversions. The
   user's configured input method (for example, ibus) pops up a
   completions menu populated with alternatives such as 各 (kaku:
   every), 描く (kaku: to draw), 核 (kaku: pit of a fruit, nucleus), 角
   (kaku: angle), etc.
7. The user uses the arrow keys to navigate the completions menu and
   select the alternative to input. As they do, the inline composing
   region in the text field is updated. It continues to be highlighted
   or underlined.
8. The user hits enter to commit the composing region. The text is
   committed to the underlying text field and the visual highlighting is
   removed.
9. If the user presses another key, a new composing sequence begins.

If a selection is present when composing begins, it is preserved until
the first keypress of input is received, at which point the selection is
deleted. If a composing sequence is aborted before the first keypress,
the selection is preserved. Creating a new selection (with the mouse,
for example) aborts composing and the composing region is automatically
committed. A composing range and selection, both with an extent, are
not permitted to co-exist.

During composing, keyboard navigation via the arrow keys, or home and
end (or equivalent shortcuts) is restricted to the composing range, as
are deletions via backspace and the delete key. This patch adds two new
private convenience methods, `editing_range` and `text_range`. The
former returns the range for which editing is currently active -- the
composing range, if composing, otherwise the full range of the text. The
latter, returns a range from position 0 (inclusive) to `text_.length()`
exclusive.

Windows IME support revolves around two main UI windows: the composition window
and the candidate window. The composition window is a system window overlaid
within the current window bounds which renders the composing string. Flutter
already renders this string itself, so we request that this window be hidden.
The candidate window is a system-rendered dropdown that displays all possible
conversions for the text in the composing region.  Since the contents of this
window are specific to the particular IME in use, and because the user may have
installed one or more third-party IMEs, Flutter does not attempt to render this
as a widget itself, but rather delegates to the system-rendered window.

The lifecycle of IME composing begins follows the following event order:
1. WM_IME_SETCONTEXT: on window creation this event is received. We strip the
   ISC_SHOWUICOMPOSITIONWINDOW bit from the event lparam before passing it to
   DefWindowProc() in order to hide the composition window, which Flutter
   already renders itself.
2. WM_IME_STARTCOMPOSITION: triggered whenever the user begins inputting new
   text. We use this event to set Flutter's TextInputModel into composing mode.
3. WM_IME_COMPOSITION: triggered on each keypress as the user adds, replaces,
   or deletes text in the composing region, navigates with their cursor within
   the composing region, or selects a new conversion candidate from the
   candidates list.
4. WM_IME_ENDCOMPOSITION: triggered when the user has finished editing the text
   in the composing region and decides to commit or abort the composition.

Additionally, the following IME-related events are emitted but not yet handled:
* WM_INPUTLANGCHANGE: triggered whenever the user selects a new language using
  the system language selection menu. Since there some language-specific
  behaviours to IMEs, we may want to make use of this in the future.
* WM_IME_NOTIFY: triggered to notify of various status events such as opening
  or closing the candidate window, setting the conversion mode, etc. None of
  these are relevant to Flutter at the moment.
* WM_IME_REQUEST: triggered to notify of various commands/requests such as
  triggering reconversion of text, which should begin composition mode, insert
  the selected text into the composing region, and allow the user to select new
  alternative candidates for the text in question before re-committing their
  new selection. This patch doesn't support this feature, but it's an important
  feature that we should support in future.

This changes the Windows text handling so that keyboard events are sent to the framework first for handling, and then passed to the text input plugin, so that the framework has a chance to handle keys before they get given to the text field.

This is complicated by the async nature of the interaction with the framework, since Windows wants a synchronous response. So, in this change, I always tell Windows that the event was handled, and if the framework (eventually) responds that it wasn't, then I synthesize a new event and send it with SendEvent.

I also added support for detecting "extended" keys, since that was missing, and converted the OnKey handlers in the API to return a bool to indicate whether or not they have handled the event.

Switches the Windows embedding from the standard C API to the new proctable version, to allow for unit testing of the embedding layer separately from the embedder APIs implementation. This includes moving some engine messaging that was still in flutter_windows to the C++ engine class to better encapsulate the proc table.

Replaces the (temporary) compile-time option to pass engine switches
with the ability to pass them temporarily at runtime via environment
variables. This moves the recently-added code for doing this on Windows
to a shared location for use by all desktop embeddings.

This is enabled only for debug/profile to avoid potential issues with
tampering with released applications, but if there is a need for that in
the future it could be added (potentially with a whitelist, as is
currently used for Dart VM flags).

Temporarily adds a way to enable mirrors as a compile time option,
as is already provided in the Linux embedding, to provide a migration
path for the one remaining known need for compile-time options
that has been raised in flutter/flutter#38569.

Replaces the (temporary) compile-time option to pass engine switches
with the ability to pass them temporarily at runtime via environment
variables.

This is enabled only for debug/profile to avoid potential issues with
tampering with released applicaitons, but if there is a need for that in
the future it could be added (potentially with a whitelist, as is
currently used for Dart VM flags).

Windows portion of:
https://github.com/flutter/flutter/issues/38569
https://github.com/flutter/flutter/issues/60393

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

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

Adds APIs for runners to delegate WindowProc handlers into the Flutter
engine, and for plugins to register as possible delegates.

This allows for plugins to alter top-level window behavior in ways that
can only be done from the WindowProc, such as resize control. This
functionality remains entirely on the native side, so is synchronous.

Part of https://github.com/flutter/flutter/issues/53168

Queries the system list of user-preferred languages, and sends it to the
engine just after starting it up.

Windows portion of https://github.com/flutter/flutter/issues/45152

Refactors the Windows embedding internals to make an engine object that
owns things associated with the engine rather than the view, and updates
the API surface to allow using the engine directly.

This is an incremental step toward both a cleaner, non-struct-based
internal structure and a finalized API surface.

* Manual roll of Dart from 24c7666def...40fd1c456e

dart-lang/sdk@40fd1c456e Revert "[dart:io] Add Abort() on HttpClientRequest"
dart-lang/sdk@17d7296a42 [vm/nnbd/bytecode] Fix reuse of type arguments in bytecode
dart-lang/sdk@58b6f40c73 Issue 42797. Understand in legacy libraries that a function returning Never (in Null Safety library) never returns. (reland)
dart-lang/sdk@fc8a6d9f9b [VM/compiler] Dereference TypeRef literal when propagating constants.
dart-lang/sdk@0689ec527a Move "test.dart" (well, most of its contents) into pkg/test_runner.
dart-lang/sdk@1094b3c61d Prepare static error test updater tool to handle web tests.
dart-lang/sdk@b258585f2f [observatory] Migrate from deprecated isInstanceOf to isA.
dart-lang/sdk@dfe1d9b682 Disable OverrideContributor for Cider.
dart-lang/sdk@aea99b2f5c scope debug property assist to Diagnosticables
dart-lang/sdk@4b96f20a79 [dart:io] Add Abort() on HttpClientRequest
dart-lang/sdk@1b1a39708c [build] Use frameworks instead of libs
dart-lang/sdk@3fef522496 Revert "Reland "[vm] Replaces fuchsia.deprecatedtimezone""
dart-lang/sdk@8c664d4f3f Revert "Issue 42797. Understand in legacy libraries that a function returning Never (in Null Safety library) never returns."
dart-lang/sdk@2efb5bebc7 [ dart:_http ] Fix typo in HTTP response timeline event
dart-lang/sdk@0884dae36c Revert "Fix the #include path for ICU headers"
dart-lang/sdk@5171534e81 Scope tweaks. Report REFERENCED_BEFORE_DECLARATION in more places.
dart-lang/sdk@6bba75079a Issue 42797. Understand in legacy libraries that a function returning Never (in Null Safety library) never returns.
dart-lang/sdk@b4ebbb7f5c [build] Update gn to match Fuchsia
dart-lang/sdk@cb428a7a02 [dart2js] Remove old bug work around in collector.
dart-lang/sdk@08663c20ab Change flutter patch to match existing DEPS on master branch
dart-lang/sdk@146ad014d9 update js/meta for the 2.10 dev sdk
dart-lang/sdk@488c718793 [co19] Roll co19 to d79951e06e443213243e54c2c32694b79a221b65
dart-lang/sdk@ba20edd7be Add patch for flutter-engine when changing to version 2.10

* Rev buildroot to latest version.

* Update license.

* update.

* Update gn revision.

* Format BUILD.gn files as the gn revision has been updated.

Implements the basic engine support for Windows for
https://github.com/flutter/flutter/issues/31952

* Add flutter_windows_view and window_binding_handler

Switch input handling infra to FlutterWindowsView

win32_flutter_window implement WindowBindingHandler

Strip unneeded functionality from win32flutterwindow

Fulfill WindowBindingHandler interface in Win32FlutterWindow

Add implementations for missing input handling in Win32FlutterWindow

Cleanup dead code

Correctly hook up rendering again

Fix resizing

clang-format

Fix clipboard

Cleanup

Rename

Add comments

cleanup

* clang-format

* CR Feedback

* clang-format; gn format

* Fix licensing

* CR feedback

* CR feedback

* CR feedback

* Git rid of unnecessar :: prefixes

* Extract WindowBindingHandlerDelegate as an interface

* Missing file

* Extract physical window bounds as a struct

* CR Feedback

* CR feedback

* clang-format
Co-authored-by: NStuart Morgan <stuartmorgan@google.com>

The embedder.h API layer is an implementation detail of the desktop
embeddings, not part of the public API surface, so should not be part of
the public symbol list for those libraries.

* Add FlTextInputPlugin

Fixes several bugs in the clipboard code, and makes some structural
improvements:
- Adds scoped wrappers for clipboard open/close and global lock/unlock,
  to prevent missing cleanup, fixing at least one case where the lock
  was not released.
- Adds the relevant window handle to the clipboard calls, since the docs
  suggest that some operations won't work without one.
- Adds a missing clear step to setting the clipboard data.
- Switches from TEXT to UNICODETEXT to handle non-ASCII text correctly.
  - To enable that, adds UTF-16/-8 conversion utilities built on the
    Win32 APIs (rather than the deprecated std::codecvt functions, as
    have been previously used in the engine).
- Fixes handling of getting data when the clipboard is empty, correctly
  returning null.
- Passes more errors back through the method channel, with details, for
  easier debugging of future issues.

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

The transitive dependency on the embedder library brings in the right
runtime for the build mode, so directly depending on the JIT version
isn't necessary, and causes duplicate symbol issues in release builds.

The JSON codec is awkward to use in the wrapper (since the client has to build and link one of the JSON libraries to do so). Since it would be very cumbersome to wrap in a C API, and there's essentially no reason to use it instead of the standard codec, this removes it from the wrapper entirely.

Since some system channels (internal to the engine) still use it, it's moved into common/cpp instead of being eliminated entirely. Internally we always use RapidJSON though, so the jsoncpp implementation is removed. Also adds some unit test coverage, since there wasn't any.

Fixes #30669

This was only necessary when the Engine had to build in multiple buildroots
where the sources where checked out at different paths relative to the
buildroot. This is no longer the case and there are already cases GN rules
have been written that mix and match variable usage with the direct
specification of the path to the Flutter sources relative to the sole buildroot.

Adds a task runner, and exposes API to allow application-level runloops to know when they need to next call the API to process engine events. Internally, sends null events to wake up the app runloop when new events are scheduled to ensure the wait time is updated accordingly.

Fixes #36420

Final portion of reworking the names of the Linux and Windows desktop build outputs.

See flutter/flutter#38589

Part of restructuring the artifacts to support transitioning away from
GLFW embeddings on desktop.

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

Start work on flutter/flutter#30726 by adding an alternative win32 shell platform implementation for Windows that is not based on GLFW and that uses LIBANGLE for rendering and native win32 windowing and input. This change does not replace the GLFW implementation but rather runs side by side with it producing a secondary flutter_windows_win32.dll artifact. The following items must be added to attain parity with the GLFW implementation:
- Custom task scheduling
- Support for keyboard modifier keys
- Async texture uploads
- Correct high DPI handling on Windows versions < 1703
and will be added in subsequent changes.

Enables the build of the Windows shell, based on the same GLFW code used
by the current Linux shell.

Changes include:
- File structure
- Header guards
- Include paths
- Namespaces
- Integration with the engine's GN build
- Conversion from jsoncpp to rapidjson
- Style and clang-format adjustment to match engine repository

The Fuchsia bots seem to reference this target to figure out the root_out_directory https://fuchsia.googlesource.com/build/+/master/dart/dart_test.gni#67. Note that the presence of the flutter_tester binary location itself is not depended on. Instead, the target is used to infer the directory containing the flutter_tester after a build.

Patching the //build repository in Fuchsia would mean making the tree red till a //topaz patch lands. To avoid doing this, we add back the missing reference.

They help the analysis service identify packages and are now mandatory on Fuchsia.