Support for FFI calls with `@Native external` functions through Native assets on Windows. This enables bundling native code without any build-system boilerplate code.

For more info see:

* https://github.com/flutter/flutter/issues/129757

### Implementation details for Windows.

Mainly follows the design of https://github.com/flutter/flutter/pull/134031.

Specifically for Windows in this PR is the logic for finding the compiler `cl.exe` and environment variables that contain the paths to the Windows headers `vcvars.bat` based on `vswhere.exe`.

To implement windows-arm64 support, it is needed to add architecture as a subdirectory (https://github.com/flutter/flutter/issues/129805).

In short, when performing a flutter windows build, we have:
- Before: build/windows/runner/Release/gallery.exe
- After: build/windows/x64/runner/Release/gallery.exe

This convention follows what flutter linux build does.

Addresses: https://github.com/flutter/flutter/issues/129805
Addresses: https://github.com/flutter/flutter/issues/116196

Design doc: [flutter.dev/go/windows-arm64](https://flutter.dev/go/windows-arm64)

Partial work towards https://github.com/flutter/flutter/issues/132245.

I also couldn't help myself to do a very minor refactor and add some comments to `LocalEngineInfo` because I was getting confused myself implementing it.

Added Regex to match error message from verbos build as suggested by @stuartmorgan [here](https://github.com/flutter/flutter/pull/98137#discussion_r810559589).
Modified Windows Build Test

Fixes #97065

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

## Background

The Windows runner has a race at startup:

1. **Platform thread**: creates a hidden window
2. **Platform thread**: launches the Flutter engine
3. **UI/Raster threads**: renders the first frame
4. **Platform thread**: Registers a callback to show the window once the next frame has been rendered.

Steps 3 and 4 happen in parallel and it is possible for step 3 to complete before step 4 starts. In this scenario, the next frame callback is never called and the window is never shown.

As a result the `windows_startup_test`'s test, which [verifies that the "show window" callback is called](https://github.com/flutter/flutter/blob/1f09a8662dad3bb1959b24e9124e05e2b9dbff1d/dev/integration_tests/windows_startup_test/windows/runner/flutter_window.cpp#L60-L64), can flake if the first frame is rendered before the show window callback has been registered.

## Solution

This change makes the runner schedule a frame after it registers the next frame callback. If step 3 hasn't completed yet, this no-ops as a frame is already scheduled. If step 3 has already completed, a new frame will be rendered, which will call the next frame callback and show the window.

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

See this thread for alternatives that were considered: https://github.com/flutter/engine/pull/42061#issuecomment-1550080722

flutter-tool: enum cleanup

[Windows] Add version info migration

[Tool] [Windows] Output app path on build completion

Revert "[Tool] [Windows] Output app path on build completion"

[Tool] [Windows] Output app path on build completion

fix devtool instructional messages after `flutter build ... --analyze-size `.  Fixes #122229 (#122230)

fix devtool instructional messages after `flutter build ... --analyze-size `.  Fixes #122229

* [Tool][Windows] Output build duration

* Tweak

* Format

You can now specify a --local-web-sdk flag to point to a wasm_release folder. This will make it so that only artifacts that pertain to the web sdk are overridden to point to the wasm_release folder. Other artifacts (such as impellerc) will pull from the cache, or from the --local-engine path if that is specified.

This also uses precompiled platform kernel files for both ddc and dart2js

Revert "[web] Add `--local-web-sdk` flag and use precompiled platform kernels for dart2js and ddc (#114639)" (#115242)

This reverts commit 0e9ee367.

* Dart2JS build step looks for compiled platform binaries.

* Use new locations of platform binaries.

* Added --local-web-sdk command line flag.

* Need to use the matching frontend server when doing ddc stuff.

* Update packages/flutter_tools/lib/src/test/web_test_compiler.dart
Co-authored-by: Mouad Debbar <mouad.debbar@gmail.com>

* Update packages/flutter_tools/lib/src/runner/flutter_command_runner.dart
Co-authored-by: Mouad Debbar <mouad.debbar@gmail.com>

* Formatting issues.

* Need to use URI format for platform dill.

* Fix resident runner tests.

* Fix analysis issue.

* Fix and add unit tests.

* Add some useful comments.

* Refine doc comments for flags.
Co-authored-by: Mouad Debbar <mouad.debbar@gmail.com>

* Check for bad characters in path on Windows build

* Doc comments

* Fix formatting

* Commenting/formatting

* Link to issue in comment

* Comments, formatting

* Global var rename

Previously developers had to edit their `Runner.rc` file to update their executable's version information. Now, version information will automatically be set from `flutter build`'s arguments or the `pubspec.yaml` file for new projects. 

Addresses https://github.com/flutter/flutter/issues/73652

When desktop support is not present in an existing project, certain
flutter tool commands raise an error that direct the user to
documentation on how to add desktop support to an existing Flutter
project. In a recent revamp of the webside, the URL was very slightly
changed (flutter.dev -> docs.flutter.dev).

This updates the error message to output the new URL.

Issue: https://github.com/flutter/flutter/issues/94398

When we landed the CMake minimum requirement constraint for Visual
Studio 2019, we landed it with minimum version 3.15, since that's what
was shipping with the current version of VS 2019 at the time. Looking at
the release notes of earlier versions, it's clear that earlier versions
of Visual Studio 2019 shipped with version 3.14. See:
https://devblogs.microsoft.com/cppblog/visual-studio-cmake-support-clang-llvm-cmake-3-14-vcpkg-and-performance-improvements/

Looking at release notes for CMake 3.15, there are no features/fixes
introduced in that version that we are dependent on.
https://cmake.org/cmake/help/latest/release/3.15.html

Issue: https://github.com/flutter/flutter/issues/88589

Depending on the user's build configuration, we may output
multi-architecture or single-architecture binaries. Prefer to install
the multi-architecture binary if built, otherwise fall back to the
single-architecture binary.

[flutter_tools] generate empty plugin registrants for winuwp and fix local engine for winuwp_ (#79827)

Adds the rest of the scaffolding for building a UWP application. The actual build functionality needs to be implemented, but could use buildWindows as an example (if it is going through cmake)

#14967