Compilation of native code to WASM

We should consider supporting compiling C code in `build.dart` to WASM and teaching dart2wasm & dart2js how to bundle/link the compiled libraries.

This feature likely needs to be owned by the dart2wasm team for dart2wasm integration. cc @eyebrowsoffire
I believe @eyebrowsoffire also had some ideas about dart2js interop with WASM.

This issue is to track what the CLI API should look like for this integration.

Currently the `BuildOutput` is tied to dynamic/static libraries that need to specify on what OS/Architecture they run.

https://github.com/dart-lang/native/blob/22f4481573c201542daa1451fc3c58b1e50bf75a/pkgs/native_assets_cli/lib/src/model/build_output.dart#L19-L25

We could relax the properties of `Asset`, but it might be better to start distinguishing different types of assets.

* `NativeCodeAsset`: The current asset.
* `WasmCodeAsset`: Compiled WASM (non-GC) code asset. With whatever properties these assets need.
* `JavaCodeAsset`: to address https://github.com/dart-lang/native/issues/645
* `DataAsset`: https://github.com/dart-lang/native/issues/154

The `BuildConfig` also needs some modification to signal to to the `build.dart` script we're targeting the web.

https://github.com/dart-lang/native/blob/22f4481573c201542daa1451fc3c58b1e50bf75a/pkgs/native_assets_cli/lib/src/model/build_config.dart#L20

Similar to https://github.com/dart-lang/native/issues/154, this also triggers the question of `package:native_assets_cli`.
We could try to only loosely couple the API by only providing the JSON/YAML format instead of a parser, but that just means `build.dart` script writers will need to write their own parser. So it's probably better to try to cover all types of assets in one protocol. So then the package should be renamed `package:build_scripts` or something.

Also, `build.dart` is currently not run in dart2wasm and dart2js. So that will need to be addressed as well.

Related issue:

* https://github.com/dart-lang/sdk/issues/46690