[native_assets_cli] Refactor API

[dcharkes]

Some open questions:

• Should we consider Linking and LinkingPreference instead of LinkMode and LinkModePreference?
• LinkingPreference { static, dynamic, any } means we cannot eagerly fail on the build in the package itself returning an error and non-0 exit code. Maybe that's okay, but it would lead to some wasted work if it's a longer build.
• hierarchical BuildConfig, discuss in:
  • [native_assets_cli] BuildConfig BuildOutput hierarchy #12
• Programmatic API for BuildOutput Initial version #3 (comment)
  • "It may be better to provide an API that one can use to add things to the output. The API can be hierarchical just like the config." -> What should this API look like? And should we separate API from implementation?

[coveralls]

coverage: 99.841%. remained the same
when pulling 83b937e on address-comments
into 5d5db9e on main.

[dcharkes]

Hey @mkustermann,

I've addressed some of your comments in this PR. PTAL, as well as to the open questions in the PR description.

[mkustermann]

Why is this a List? As we can have only 2 entries and only one of them could be our preferred way.

[dcharkes]

I didn't touch this yet because of :

LinkingPreference { static, dynamic, any } means we cannot eagerly fail on the build in the package itself returning an error and non-0 exit code. Maybe that's okay, but it would lead to some wasted work if it's a longer build.

Let's solve that question first, then I clean this up.

[dcharkes]

Some of the refactorings need some more discussion, I've opened issues to track these:

• [native_assets_cli] BuildConfig BuildOutput hierarchy #12
• [native_assets_cli] BuildOutput API #25

Merging this with the first batch of refactorings.