fix(clion): Add Xcode information to Cpp compiler wrapper

[blorente]

Checklist

• I have filed an issue about this change and discussed potential changes with the maintainers.
• I have received the approval from the maintainers to make this change.
• This is not a stylistic, refactoring, or cleanup change.

Please note that the maintainers will not be reviewing this change until all checkboxes are ticked. See
the Contributions section in the README for more
details.

Discussion thread for this change

Issue number: N/A (sorry, I didn't open one).

Description of this change

In CLion, the Bazel plugin has to pass a C compiler to the rest of the CLion machinery.
Currently, on macOS, if using the standard cc toolchains, it does so by wrapping the clang_wrapper.sh we get from each toolchain implementation. On macOS, that wrapper expects the environment variables DEVELOPER_DIR and SDKROOT to be set. In Bazel, they are set on every action. Currently, in CLion, they are not, which makes a lot of the smarts of CLion inaccessible to macOS users.

This PR sets those variables by mirroring Bazel's logic:

• When resolving Compiler Settings, cquery for the xcode version in @bazel_tools//tools/osx:current_xcode_config.
• Then, use the xcode locator that Bazel uses to translate the DEVELOPER_DIR that corresponds with that version. (This is where Bazel does it).
• The rest is just piping those values so that they end up as environment variables in the compiler wrapper.

Note that we could have gotten the xcode version from the aspect, and saved ourselves a potentially expensive cquery. But, due to this issue, we cannot forward those values to the rest of the build.

[raoarun]

ECD 27 April 2023 to be merged as per @tpasternak

[tpasternak]

Thank you, good job!

The only major issue I see here is that we ignore stderr output in both query calls, which can lead to some hard-to-spot silent crashes, so personally I'd prefer to pipe stderr to the Bazel tool window

[tpasternak]

We lose error stream here if the query result is 0. I think this is the reason for which it was possible to skip != None check in QUERY_XCODE_VERSION_STARLARK_EXPR - the error message was silenced

[blorente]

Great point! Piped it through the context.

[blorente]

@tpasternak If CI passes, I think this is ready for another review.

[tpasternak]

Suggested change

	XcodeCompilerSettings expected = new XcodeCompilerSettings(Path.of("/tmp/dev_dir"), Path.of("/tmp/dev_dir/sdk"));
	XcodeCompilerSettings expected = XcodeCompilerSettings.create(Path.of("/tmp/dev_dir"), Path.of("/tmp/dev_dir/sdk"));

Otherwise, it won't compile as XcodeCompilerSettings is now abstract

[blorente]

Thanks! After a small fire at work I finally got time to make the tests pass.
There was this thing and another small thing related to turning it into a project service, then it's all done :D