* Don't terminate Dart process pids from VM Service

These processes may be on another device, and in the case of attach the debugee should not be terminated anyway.

This reverts commit dd5ed7cf.

In the run_release_test_macos integration test that verifies that a
release build of an app can be launched (and quit), xcodebuild from the
Xcode install on the macOS bots emits a few info messages about
Simulator SDK versions that are irrelevant to the functioning of this
test.

Ignore these instead of failing the test if they occur.

Related: https://github.com/flutter/flutter/pull/100526

Issue: https://github.com/flutter/flutter/issues/100348 (fix)
Issue: https://github.com/flutter/flutter/issues/97978 (partial fix)
Issue: https://github.com/flutter/flutter/issues/97977 (partial fix)
Umbrella issue: https://github.com/flutter/flutter/issues/60113

Adds a test that invokes flutter run in release mode on macOS desktop,
waits for successful launch and the flutter command list, then sends the
'q' command to quit the running app.

This adds an integration test for https://github.com/flutter/flutter/pull/100504.

Issue: https://github.com/flutter/flutter/issues/100348 (fix)
Issue: https://github.com/flutter/flutter/issues/97978 (partial fix)
Issue: https://github.com/flutter/flutter/issues/97977 (partial fix)
Umbrella issue: https://github.com/flutter/flutter/issues/60113

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.