feat: expands options for setting pixi-build override options

[tdejager]

This expands the options for overriding the build backends, which can be very useful when testing stuff out. This also changes how different build protocol implementations react to this override.

The problem with the way that it was previously done is that the override could only be done for one build backend which would be applied to all build backends. So if you override pixi-build-python it would also override pixi-build-cmake with the override, which made it somewhat useless.

I've now added more elaborate machinery where we can override each backend individually, you can also choose to override all backends with the system installed once, this assumes access on a system level and that the names of the specs and executables match up.

tl;dr

If PIXI_BUILD_BACKEND_OVERRIDE_ALL is set it will override all backends.
If not it will check the PIXI_BUILD_BACKEND_OVERRIDE environment variable.
This variable should be in the form of tool_name=/path/to/executable::tool_name2.
Where the :: is used to separate different tools. and the = is used to separate the
tool name from the path. If no path is provided the tool is assumed to be available in the
root.

Testing

I've tested by using this branch (prefix-dev/pixi-build-backends#47) that kind of breaks the protocol and used the environment variables for testing the override.

Giving me something like in the boltons and cpp-sdl example:

 PIXI_BUILD_BACKEND_OVERRIDE_ALL=1 pixd build                                                                                                                                                                     ─╯
 WARN overriding build backend with system prefixed tools
Error:
  × unable to setup the build-backend to build the project
  ├─▶ received invalid response from the build backend (pixi-build-rattler-build) when calling 'initialize'
  ╰─▶ missing field `capabilities`

Unsure how I can nicely test this in CI.

[baszalmstra]

Why not use , as a seperator? 😺

[tdejager]

Why not use , as a seperator? 😺

Don't really have a preference :P, I figured that could be part of a path, I've asked Gary what would be something that is not likely in a path and he suggested this or weird unicode stuff, so I went with his least worst idea 😎 Happy to change though.

[baszalmstra]

Let's use , then because thats what I would expect without reading the docs.

[tdejager]

Done!