[native_assets_cli] JSON protocol nest per asset type

[dcharkes]

In the JSON protocol nest the config only for native code assets under the native key.

Pro:

• Not every asset type or builder will need access to all information. E.g. a data asset probably doesn't need access to the the target architecture or minimum iOS SDK.

Con:

• Fields needed for multiple asset types (but not asset types) would be duplicated. E.g. the targetOS might be used for some asset types e.g. different icons on iOS vs Android. It would need to be duplicated in the nested keys.

In the JSON protocol nest the native code assets under a native key, nest the data assets under a data key.

Pro:

• Different asset types do not need to share any structure. E.g. a jar doesn't need an assetId, because it will be never accessed from Dart code. (Note that this is kind of a non-argument as long as we have a type field for assets, because it makes it like a tagged union.)

Sister issue for the API:

• [native_assets_cli] Dart API interface per asset type #994