Adds a cargo wrapper script for closer integration with Xcode projects

[akitchen]

In order to reduce the friction of integrating rust crates into existing complex C++ projects on Apple platforms, this PR introduces a script phase in the generated Xcode project which is capable of interpreting the environment variables set by Xcode during the build. This makes it possible to drive cargo rustc more dynamically without needing to regenerate the project, significantly improving development experience on Apple platforms when integrating rust into existing complex multi-SDK projects.

This solution has been in use on a large proprietary project for a while now and is working well for our purposes. Opening this Draft PR for discussion since a few details would likely need to be ironed out before upstreaming into Corrosion.

• The library created by cargo rustc is not seen as a "native target" by Xcode and needs to be linked manually as a one-time configuration step. Maybe this isn't so bad but I'd still like to see if this can be improved. Otherwise it would need to be documented clearly.
• This could be seen as introducing technical debt or conflicting approaches to Xcode integration, when compared to the single-configuration codepaths evolving in Corrosion. More discussion is likely needed as to how a developer should opt in to this functionality, or whether all Xcode builds should work this way instead of a single-configuration mode.
• This PR also includes an unrelated change to allow the developer to specify a list of Debug-like configurations, because our project uses some non-standard configuration names.

I wonder what ideas the maintainers or community might have when it comes to improving on this, or if there are any better solutions to this problem. Thank you for an otherwise very useful project!

[jschwe]

This PR also includes an unrelated change to allow the developer to specify a list of Debug-like configurations, because our project uses some non-standard configuration names.

What is the use-case for this? Is it simply to manage the default mapping to --debug vs --release profiles? You could already do something similar by specifying a profile with a custom generator expression.

significantly improving development experience on Apple platforms when integrating rust into existing complex multi-SDK projects.

Is the list of SDKs that the user wants to support known at configuration time? Corrosion does some configure-time checks, including checking which native libraries a default rust project needs to link to on the given platform, so it would be helpful if we had a list of targets that are potential targets when configuring.

The library created by cargo rustc is not seen as a "native target" by Xcode and needs to be linked manually as a one-time configuration step. Maybe this isn't so bad but I'd still like to see if this can be improved. Otherwise it would need to be documented clearly.

How does this look like? I'm not familiar with how CMake is integrated into XCode (or XCode at all really), so I'm missing quite a bit of context here.

[jschwe]

@ogoffart I'd also be interested on your teams opinions on multi-SDK support, since AFAIK you also target mac and iOS, so you are probably much more familiar with XCode than me. See also #649 (comment) for a bit more context.