Refactor option getting v2

[jpakkane]

This is basically a rebased version of #13086. Well, half of it currently. Will do the rest after this.

The refactor operation turned out to be so big I though it better to open a new one and leave that MR exist in its original state in case it is ever needed for debugging. Will close that once this is merged.

This has a bunch of broken commits and fixing them would be too much work, so this must be merged with a merge commit rather than rebasing.

[jpakkane]

Cherry-picked the relevant remaining commits. Expect everything to be still broken. Will work on fixing things again next.

[jpakkane]

Fixed enough that all common tests pass. Feel free to start reviewing those bits.

No point in commenting on typing, though, it has not been done at all.

[jpakkane]

Now passes all project tests.

On my machine.

[dnicolodi]

The first tow times I read "augment" I thought it was "argument" misspelled. IIUC, augments are subproject-specific options. Can't the concept be called "subproject-specific option" instead of "augment"? I think it would be clearer and I don't think it need to be written so often for the lengthy name to be a problem.

[jpakkane]

Originally I wanted to call it "override", but that is already used for per-target option values, so no. I guess we can call them "subproject specific options" in docs, but internally we need a more concise name. And in any case it would be nice to have the same name for this feature internally and externally.

"Augment" was the best I could come up with, better ideas welcome.

[eli-schwartz]

dumb thought: call it an augmentation instead of an augment and no one will get it confused with an argument?

[andy5995]

"Augment" was the best I could come up with, better ideas welcome.

Supersede or Negate might be considered. But expanding them to "supersedes" or "Negates" or "Negations" fouls things up. Then there is supersession, where the main advantage is that it's a long way from `argument'. ;)

[dcbaker]

I'm going to say again, for the last time because I don't feel like I actually have any power here that:

1. I'm still not convinced that I like the command line, and I really wish that this had been developed as a number of smaller series that would have allowed better review. Specifically splitting the refactoring of the implementation and the changes to the command line. But that's water under the bridge at this point.
2. It's really frustrating that I feel like when I (who also have limited Meson development time) send huge series they are expected to meet the same standards as all other series, ie: each patch must be complete, and work without regression, while making one logical change.
3. I still think this is a terrible approach. the optstore is a divine object antipattern, you can't do anything with options without it, not even calculate the key that an option can use. So now we have to pass the optstore into everything, where previously we had numerous, small, simple objects that were self contained. It also goes back to stringly typing a bunch of stuff that used to have unique types associated with them

I don't feel like I'm going to make any headway here on my design concerns so I'll stop now. But I really feel like after this merges Eli and I are going to spend a significant amount of time fixing all of the issues that this MR introduces.

I have no more comments to make on this, so just merge it.