[native_asserts_cli] ☂ Make `native_toolchain_c` more usable standalone

[dcharkes]

It would be good to try to split package:native_toolchain_c a more from package:native_assets_cli.

Make a programmatic API that enables using native_toolchain_c more standalone, and a wrapper function that reads HookInput and produces a HookOutput.

Use cases:

• It would be relatively straightforward to modify such wrapper function to have different-than-default behavior. C Toolchain: Add option to not include sources in dependencies #1998
• Switch CBuilder to return assets and dependencies #1131
• Enable using the package in standalone scripts that are not hooks (e.g. in a tool/build.dart).

I'm not entirely sure where the split should be. Maybe we should have a Future<CBuilderOutput> run2(CBuilderInput input). That would allow the constructors (which contains all configuration which is not in the hook input) to stay the same whether you use CBuilder from a hook, from a hook but not with default behavior, or from a tool script. (The names should probably be better than run and run2. 🤓)

[MichealReed]

The native_toolchain, tool, and utils helpers in the toolchain_c package might be more ripe for the toolchain_cli package. Other build systems could benefit from these without the CBuilder.