Refactor getting option values

[jpakkane]

Currently option values for a target are store in the target object as a "view". This works for the current setup but is very inconvenient for #9398. This MR refactors things both to make things simpler and to make overriding values from the command line possible.

• Eventually build objects shall only contain "raw data" and computing "option values" for them
• Backends shall use the methods added to the base backend class
• get_option shall use a similar sort of centralised method (not yet added)
• Both of these shall (probably) use the same implementation somewhere

This is WIP and will probably fail tests on other platforms. Do not merge yet, I need to add and squash things as outlined in the first commit message before this is ready.

This needs to be merged with a merge commit, because the intermediate commits are many and definitely not working so rebasing would break bisect.

[jpakkane]

This is ugly as sin, but it now finally works on Linux at least (more specifically run_project_tests.py --only common does not produce any errors).

There is no actual override ability yet, but it should be fairly straightforward to add on top of this.

This requires a bunch of cleanup before it can be considered for merging. But at least the groundwork is there.

[jpakkane]

Now it works enough to run the brand new unit test. Do read it to get a grasp on how this is supposed to be used. Design comments welcome, actual code is missing a ton of cleanup still so maybe hold off on that unless you see something egregious.

[jpakkane]

The unit test that checks per project overrides now passes, but a ton of other unit tests have started failing. Next I need to fix those.

It seems that this requires writing a new class OptionDatabase or somesuch that concentrates all the complexity of option handing in one place as opposed to the current approach, where the functionality is spread everywhere.

[jpakkane]

I have started hooking up the new functionality to the main code. This has covered both expected and unexpected issues. Will keep on hammering them.

There are currently 73 failing common tests.

[jpakkane]

The tests that fail in common divide into two camps: behaviour that might actually not make sense and native/cross files. The former requires a policy decision. The latter on the other hand requires a fair bit of refactoring. One hopes that it won't duplicate the amount of work needed for this.

[jpakkane]

This now works "enough" for people to start testing it. There are a lot of broken things still (for example cross compilation is completely broken) so please report general issues rather than individual minor bugs. Trying it out is simple:

• Take a project that has subprojects
• Configure it as usual (if it fails, try a simpler project)
• Compile with '-vand check that optimization is-O0`
• meson configure -Asubproject:optimization=2
• Compile again with -v, subproject should now have optimization enabled
• meson configure should list the augment int its output
• meson configure -Usubproject:optimization
• Compile again, optimization should be gone
• meson configure -A:optimization=2
• Compile again with -v, now the top level project (and only that) should have -O2
• meson configure -U:optimization should remove it again

This should work for all builtin options (i.e. not-project options) but I have only tested this one flag.

Option values defined in subproject project calls and in subproject default_options should be stored as augments so you can edit and remove them from the command line. (might now work yet)