Question: Project options and chaining conditionals

Hi, me again. Apologies in advance for so many new issues.

This time in cross-compile land, I have a couple project options in my `project.conf`:

```
options:
target_arch:
type: enum
variable: target_arch
values:
- aarch64
- arm
- armhf
- x86_64
default: x86_64

platform:
type: enum
variable: platform
values:
- generic # No platform-specific elements added to the image
- rpi32 # + RPi Bootloader & Broadcom blobs, only the 32-bit ones though
- rpi64 # + RPi Bootloader & Broadcom blobs, only the 64-bit ones though
default: generic
```

This is a simpler example than what I would end up with, but let's say we can't change the above, just to illustrate the issue: I want to support building for a Raspberry Pi, both 32- and 64-bit, as well as a x86_64 -> x86_64 cross-compile for simulation and debugging purposes.

Currently, if I want to build the "generic" platform, I can simply say `$ bst -o target_arch x86_64 build os/image.bst` to build an OS image that has no platform-specific elements, and then say `$ bst -o target_arch aarch64 build os/image.bst` to build a "generic" aarch64 image that also has no platform-specific things (maybe we want to Qemu it or work on porting it to a new board).

How would I allow a user to also say `$ bst -o platform rpi64 build os/image.bst` to build for a supported Raspberry Pi platform and have BuildStream automatically select `aarch64` as the `target_arch` based on the `platform` option? Do I really need to specify both options in the command line like `$ bst -o platform rpi64 -o target_arch aarch64 build os/image.bst`? Conditionals being able to set values that other conditionals can use seems like it should be a supported thing -- Again, it's going to be more complex than this later, and needing users to specify a bunch of different options when there's only a few valid option combinations isn't the best.

I've tried a couple things that feel like they should work, but aren't supported by BuildStream. First, resetting the "default" seemed obvious, but it didn't like that:

```
(?):
- platform == "rpi32":
options:
target_arch:
default: armhf
- platform == "rpi64":
options:
target_arch:
default: aarch64
```

Then I thought maybe just setting the variables should work, but that didn't actually change the value of the project option when later doing a check:

```
(?):
- platform == "rpi32":
variable:
target_arch: armhf
- platform == "rpi64":
variable:
target_arch: aarch64
```

```
(?):
- (platform == "rpi64" and target_arch != "aarch64"):
(!): |
Error rpi64 != aarch64 ???
- (platform == "rpi32" and target_arch != "armhf"):
(!): |
Error rpi32 != armhf ???
```

Then I saw you could pass in a "-c " arg, where you could then do something like: `$ bst -c config/rpi64.conf build os/image.bst` and just manually place the config values in a config file in the same repository:

```
projects:
my_os:
options:
target_arch: aarch64
platform: rpi64
```

Not a terrible compromise, but then I realized that by doing so it doesn't honor the user's `.config/buildstream.conf` file... So that also doesn't work.

What's the answer? :)

I see FreeDesktopSDK has a Makefile that sets these things, but that seems like a band-aid to something that should be handled by the build system.

Thanks! (Not trying to be too harsh, just an honest evaluation)

The issue does not name a source file, test, or entry point. Start by tracing BuildStream's project-option, conditional, and configuration-file handling; done would mean establishing whether a platform selection can consistently derive target_arch while preserving the user's existing configuration.

Written by the indexing model from the issue text.