[ffigen] Improve API for clang args #3630

At the moment the config API gives you two options for passing args to clang, using Input.compilerOptions:

1. Use the defaults, which work for 90% of cases
2. Pass custom args, overwriting the defaults

The default params depend on:

• the host OS
• the target language specified in the config
• probably other config elements in future (especially with C++ support in the works)
• some non-trivial logic that attempts to find system headers

Often what users want is to add extra args to the defaults, not replace them. Users shouldn't have to replicate our complicated default arg logic. In my own configs, I often end up importing some of the internal utils that calculate the default args.

Option 1: Expose utils

The obvious solution would be to clean up and expose those internal utils. That's a bit fiddly because the args depend on elements from the config. There's no clean way of building that API, aside from asking the user to repeat themselves (eg specify the target language in both the config and this arg calculation util).

There are other options for this approach, but nothing particularly clean.

Option 2: Non-breaking API change

We could change List<String>? compilerOptions to allow adding to the defaults. For example, we could accept a sentinel string, like "DEFAULT_ARGS" that we replace with the defaults. Or we could make it a List<String?> and use null as the sentinel.

A less hacky solution would be to add another field to Input, like bool appendCompilerOptions, which means the compilerOptions are appended to the defaults instead of replacing them. Not as clean as I'd like, but this is the approach I lean towards.

The downside of these approaches is that the user still has to take all the defaults, or none of them (though they can override the defaults since later args overwrite earlier ones).

Option 3: Breaking API change

We could also consider changing compilerOptions from a List<String> to some sort of structured object. We would have fields for each arg we currently set, each of which is nullable, and if the field is null then the default is used. The object would also still have a List<String> for other options.