[macOS] Use arm64 snapshot in arm64 App.framework

[cbracken]

Previously, #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: #100348

Pre-launch Checklist

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

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

[skia-gold]

Gold has detected about 1 new digest(s) on patchset 1.
View them at https://flutter-gold.skia.org/cl/github/100504

[skia-gold]

Gold has detected about 1 new digest(s) on patchset 1.
View them at https://flutter-gold.skia.org/cl/github/100504

[jmagman]

This change LGTM.
Recommend an integration test to validate the macOS test runs in release mode.
Suggest a macOS version of https://github.com/flutter/flutter/blob/master/dev/devicelab/bin/tasks/run_release_test.dart
See https://github.com/flutter/flutter/blob/master/dev/devicelab/bin/tasks/hot_mode_dev_cycle_macos_target__benchmark.dart for example of macOS test.

[zanderso]

lgtm

[zanderso]

This change LGTM. Recommend an integration test to validate the macOS test runs in release mode. Suggest a macOS version of https://github.com/flutter/flutter/blob/master/dev/devicelab/bin/tasks/run_release_test.dart See https://github.com/flutter/flutter/blob/master/dev/devicelab/bin/tasks/hot_mode_dev_cycle_macos_target__benchmark.dart for example of macOS test.

+1

[cbracken]

Sounds good; I'm going to land this to get master unbroken on M1 machines. Sending a followup patch that adds the devicelab test momentarily.

[cbracken]

Integration test added in #100526.