Previously, https://github.com/flutter/flutter/pull/100271 enabled
building universal macOS binaries by default, but included a bug causing
the arm64 App.framework to be built such that the TEXT section
containing the app instructions built by gen_snapshot incorrectly
contained x86_64 instructions rather than arm64 instructions.

When building macOS (and iOS) apps, Flutter builds them in three
components:
* The Runner application: built by Xcode
* The bundled App.framework: built from assembly code generated by
  gen_snapshot from the application's Dart sources.
* The bundled FlutterMacOS.framework: built as part of the engine build
  and packaged by copying the distributed binary framework from our
  artifacts cache.

Building App.framework consists of the following steps:
* For each architecture, invoke gen_snapshot to generate
  architecture-specific assembly code, which is then built to object
  code and linked into an architecture-specific App.framework.
* Use the `lipo` tool to generate a universal binary that includes both
  x86_64 and arm64 architectures.

Previously, we were building architecture specific App.framework
binaries. However, for all architectures we were (mistakenly) invoking
the general `gen_snapshot` tool (which emitted x64 instructions, and
which is now deprecated) instead of the architecture-specific
`gen_snapshot_x86` and `gen_snapshot_arm64` builds which emit
instructions for the correct architecture.

This change introduces a small refactoring, which is to split the
`getNameForDarwinArch` function into two functions:
* `getDartNameForDarwinArch`: the name for the specified architecture as
  used in the Dart SDK, for example as the suffix of `gen_snapshot`.
* `getNameForDarwinArch`: the name for the specified architecture
  as used in Apple tools, for example as an argument to `lipo`. For
  consistency, and to match developer expectations on Darwin platforms,
  this is also the name used in Flutter's build outputs.

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

We are working towards following OpenSSF best practice recommendations
for flutter/flutter. This badge presents our current progress in this
effort.

* fix deprecated_new_in_comment_reference for `material` library

in a future version of the SDK, these will be flagged, fix them now

* Update pubspec.yaml

* first pass

* x

* x

* address feedback

* support multiple extensions

* add convenience function, Object ⇒ dynamic, lerping

* remove not-useful comment

* fix examples/api lower sdk constraint

* remove trailing spaces

* remove another pesky trailing space

* improve lerp

* address feedback

* hide map implementation from constructor and copyWith

* use iterableproperty

* Revert "hide map implementation from constructor and copyWith"

This reverts commit a6994af0046e3c90dbc9405cac628feb5b2d3031.

* slow down sample

* make theme extension params required

* add null check

* improve documentation

* fix hashCode and operator == overrides

* modify existing tests

* remove trailing spaces

* add all tests except lerping

* fix lerping bug

* add toString to themeExtension example

* add lerping test

* assume non-nullability in example

* address feedback

* update docs

* remove trailing space

* use Map.unmodifiable