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)

Some files are supposed to ignore, but don't.

- **/windows/flutter/generated_plugins.cmake
- **/linux/flutter/generated_plugin_registrant.cc
- **/linux/flutter/generated_plugin_registrant.h
- **/linux/flutter/generated_plugins.cmake
- **/windows/flutter/generated_plugin_registrant.cc
- **/windows/flutter/generated_plugin_registrant.h
- **/ios/Runner/GeneratedPluginRegistrant.h
- **/ios/Runner/GeneratedPluginRegistrant.m

*List which issues are fixed by this PR. You must list at least one issue.*

*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*

~Update the windows app template and migration to use `CMP0135` when
cmake version is >= 3.24.~

Update app templates' and examples' CMakeLists.txt to use
`cmake_policy(VERSION`. https://github.com/flutter/packages/pull/3828
should obviate the need for a migration.

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

## Pre-launch Checklist

- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [ ] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel
on [Discord].

<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#overview
[Tree Hygiene]: https://github.com/flutter/flutter/wiki/Tree-hygiene
[test-exempt]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo
[Features we expect every widget to implement]:
https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#features-we-expect-every-widget-to-implement
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes
[Discord]: https://github.com/flutter/flutter/wiki/Chat

* Fix typos

* lowercase animated & opacity

* Undo typo fix

---------
Co-authored-by: Michael Goderbauer <goderbauer@google.com>

---------
Co-authored-by: schectman <schectman@google.com>

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

This patch adds an additional check to ensure the target length of a string is within the supported maximum string length prior to calling WideCharToMultiByte/MultiByteToWideChar in the Windows runner template.

This is to prevent resize() from failing if called with a count > std::string::max_size().

According to Win32 API docs (WideCharToMultiByte, MultiByteToWideChar) it's the caller responsibility to make sure the buffers are correctly allocated.

Authored by: Tomasz Gucio <tgucio@gmail.com>

This adds a smoke test for every single API example. It also fixes 17 tests that had bugs in them, or were otherwise broken, and even fixes one actual bug in the framework, and one limitation in the framework.

The bug in the framework is that NetworkImage's _loadAsync method had await response.drain<List<int>>();, but if the response is null, it will throw a cryptic exception saying that Null can't be assigned to List<int>. The fix was just to use await response.drain<void>(); instead.

The limitation is that RelativePositionedTransition takes an Animation<Rect> rect parameter, and if you want to use a RectTween with it, the value emitted there is Rect?, and one of the examples was just casting from Animation<Rect> to Animation<Rect?>, which is invalid, so I modified RelativePositionedTransition to take a Rect? and just use Rect.zero if the rect is null.

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

This extracts the sample code out from the API doc comments, and places them in separate files on disk, allowing running of the examples locally, testing them, and building of slightly larger examples.