[native_assets_cli] Provide a `Builder` abstraction

[dcharkes]

package:native_assets_cli defines:

abstract class Builder {
  Future<void> run({
    required BuildConfig config,
    required BuildOutput output,
    required Logger? logger,
  });
}

class CBuilder implements Builder {

In a sketch for an asset downloader we also have

class AssetDownloader implements Builder {

We should probably standardize the Builder interface somewhere so that they are composable.

This interacts slightly with hiding fields from the BuildConfig that aren't used:

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

It most likely means that run method implementing the interface should immediately shell out to another method that takes the interfaces/extension types that only show a subset of the getters on BuildConfig, and the more specific methods on BuildOutput.

Related issues:

• [native_assets_cli] BuildOutput behaves like a sink, should it behave like a bag? #1167

[dcharkes]

We do the same for linker:

abstract class Linker {
  Future<void> run({
    required LinkConfig config,
    required LinkOutput output,
    required Logger? logger,
  });
}

class CLinker implements Linker {

We don't want a shared run:

abstract class Linker {
  Future<void> run({
    required HookConfig config,
    required HookOutput output,
    required Logger? logger,
  });
}

Reasoning for not having a shared run is that caching behavior is different for build hooks and link hooks. Build hooks are rerun much less often than link hooks. So downloading assets and building code should always be done in the build hook, even if the dylib might not be included in the end. (If you only download or build in the link hook, you might save a build or download on the first run, but it will have to be rerun very often.)