[native_assets_cli] data assets

[dcharkes]

trafficstars

Initially, we had the idea that the input and output for build.dart would be unstructured JSON/YAML, and that there would be multiple views on top of these JSONs. In this approach, package:native_assets_cli would be one such view. And we would introduce other views for other types of assets (icons, localization) ...

However, after some discussions with @mosuem, we realized that some of the things in the JSON would be better off shared:

• In the BuildOutput: the dependencies (used for caching -- whether build.dart should be reinvoked). This would also be required for resource shaking in localization.
• In the BuildConfig the targetOS would likely be used for deciding what icons to bundle.

If we add a concept of "data assets" to the native assets CLI, then we should reconsider the package name package:native_assets_cli to be something like package:build_script instead. (Suggestion taken from @gaaclarke)

For some reason the name "native assets" made it seem like it was only for linking in libraries. IMO "build scripts" is a better name.

Dart SDK tracking issue:

• https://github.com/dart-lang/sdk/issues/54003

Flutter tracking issue:

• https://github.com/flutter/flutter/issues/146264

[gaaclarke]

I also found native_assets_cli confusing because the user of the package never actually gets a command-line interface. I thought maybe that was some command-line tool that would setup the environment so that native_assets would work.

[dcharkes]

Package rename is tracked in:

• https://github.com/dart-lang/native/issues/999

[dcharkes]

Data assets are part of the protocol now, and the protocol is extensible. They have not been implemented in Dart and Flutter yet, but that's tracked by separate issues.