[native_assets] Record bundled code assets under their install name (#190819)

On macOS and iOS, `flutter_tools` stamps a bundled code asset's
framework with the install name
`@rpath/<name>.framework/<name>`, but records that asset in
`NativeAssetsManifest.json` as
`<name>.framework/<name>`. The manifest entry is the string the Dart VM
hands to `dlopen`, so the two
never match. dyld cannot recognize the library under a name it has no
install name for, so it falls
back on identifying the file on disk, and that identity only holds until
the file is replaced.
Rebuilding an app while a debug instance is still running replaces it,
so the next lazily resolved
`@Native` binding maps a second copy of the asset into the process. Two
copies of a C library do not
share its global state, and a handle produced by the first copy is not
valid in the second. For
`package:sqlite3` that is a segfault on the first write after a rebuild,
and the operation is lost.

Both strings now come from one `frameworkInstallName` helper, so the
name stamped into the framework
and the name recorded in the manifest cannot drift apart again. The
framework is still bundled at the
unprefixed path, and
`DarwinAddToAppNativeAssets.parseNativeAssetsManifest` drops the prefix
for the
add-to-app and Swift Package callers that use the manifest to find the
framework on disk.

The `flutter test` path is unchanged. The tester loads the dylib from
where it was built and its
install name is already the absolute path that the manifest records,
which is why `dart run` and
`flutter test` never showed this.

Fixes https://github.com/flutter/flutter/issues/190799

The reporter of that issue measured the dyld behaviour on macOS,
including that a manifest entry of
`@rpath/<name>.framework/<name>` resolves through `dlopen` and leaves a
single mapping across a
rebuild. iOS goes through the same helper and had the same mismatch, so
it is fixed here too. I do
not have a Mac, so beyond the unit tests added here I am relying on the
existing macOS native assets
integration tests (`flutter run` with a bundled code asset, in all three
build modes) on CI.

## Pre-launch Checklist

- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [AI contribution guidelines] and understand my
responsibilities, or I am not using AI tools.
- [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].
- [x] 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] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.

<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview
[AI contribution guidelines]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#ai-contribution-guidelines
[Tree Hygiene]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md
[test-exempt]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md
[Features we expect every widget to implement]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement
[CLA]: https://cla.developers.google.com/
[breaking change policy]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes
[Data Driven Fixes]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md