[native_assets_cli] Document the protocol

[dcharkes]

Currently, the protocol between the Dart (and Flutter) SDK and packages' build.dart is specified by its implementation in package:native_assets_cli. This package also provides a way to parse and unparse the protocol.

@jonasfj mentioned it could be that the community likes to reimplement the protocol in another package. For this, we would need to specify the protocol (in a markdown file for example).

[jonasfj]

It also makes it easier to track if changes are breaking or not, and forces you to be intentional about what the Dart SDK requires, and what is an implementation detail added for easy debugging.

[dcharkes]

Most probably, we'd want to use the JSON schema for documenting the protocol.

We'd have multiple schemas:

• input for build hooks
• input for link hooks
• output for build hooks
• output for link hooks
• (there is currently no config/input for data assets)
• input for code code assets
• output for data assets
• output for code assets

With schema evolution / breaking changes (#93) we'd like to

1. be able to mark fields as deprecated, which is possible with https://json-schema.org/draft/2019-09/json-schema-validation#rfc.section.9.3
2. be able to document semantic changes to fields. Maybe we'd do so in the description field.

(For FFIgen we have a schema generator for the config, we should consider having something similar. Then we'd probably want to generate also the Dart classes that do the JSON parsing and instead of operating on the JSON operate on the serializable Dart classes in the implementation. #1826)

[dcharkes]

After #2116, the protocol is fully documented in schemas.

We haven't added descriptions to the schemas so far. We could do so. However, the schemas are close enough to the Dart API that I think the documentation can be inferred from that.