[native_assets_cli] BuildConfig BuildInfo versioning

[dcharkes]

Since these two formats are the interface between packages and dartdev/flutter_tools, we should probably version them.

Hopefully we can make 100% backwards compatible changes since these are just yaml, but having a version number would be good.

If the major version number does not align, we have multiple modes:

1. The packages' build.dart does not know how to interpret a BuildConfig of a newer major version number, and will consequently fail. Fix: that package needs to bump their package:native_assets_cli dependency and release a new version.
2. The packages' build.dart does not know how to interpret a BuildConfig with an old major version number, and will consequently fail. (This can only happen if a package is newer than the SDK.) Fix: install a newer Dart/Flutter.
3. dartdev/flutter_tools don't know how to interpret a BuildInfo with a newer/older major version. This can only happen if we don't version BuildInfo and BuildConfig together. Fixes: update the package / update Dart/Flutter.

Mitigations:

• Keep the parser for older versions around in the BuildInfo and BuildConfig fromYaml factories. Though, this will only work if we do syntactic changes but have the same set of information.
• The BuildInfo and BuildConfig protocol should be versioned separately from package:native_assets_cli. The package can have breaking Dart API changes while not doing breaking protocol changes. We shouldn't introduce unnecessary major version bumps in the protocol.

We should strive to make breaking changes to the protocol as minimal as possible.

Related issues:

• [native_assets_cli] BuildConfig BuildOutput hierarchy #12 (comment)