Support accessing members of a conditional value

[ranma42]

This changeset adds support for accessing a member of the result of a conditional expression.

It achieves this by folding the member access into the conditional.

Fixes #34589.

[ranma42]

Note that the updated baselines point to a missing CASE simplification (CASE WHEN nonNullableX THEN TRUE ELSE FALSE END -> nonNullableX).
Additionally, the test I implemented currently hits #28077 (neither join is really needed).

I would like to add a couple of missing test cases before marking as ready:

• different subclasses of a same type (see point 2 in Support projecting different navigations (but same type) via conditional operator #34589 (comment) )
• select'ing the conditional, then accessing multiple members

I am also thinking that it might be a good idea to write the tests so that they do not interact with #28077, so I will probably end up rewriting the existing test. What is the best place for these tests? (if I want to check the behavior on different subclasses, maybe InheritanceQueryTestBase makes more sense 🤔 )

[ranma42]

I extended the tests and kept them in GoW, as the different handling of subclassing is interesting.
In order to implement Conditional_Navigation_With_Member_Access_On_Related_Types I extended LocustHorde, which has the unfortunate side-effects of changing unrelated tests (adding a column in several SELECT queries).
I would love recommendations on possible improvements.

[Xriuk]

Just to add that this might be more complex: property/fields access might also include type casts in the chain.
Also it might be worth supporting comparison operators and also method invocations too (instance methods and static/extensions)?

[ranma42]

@Xriuk I will probably restrict this changeset to a more limited scope; the various types of expressions are (at least in part) handled by different translators, so to handle this in full generality some heavy restructuring of the translation pipeline might be needed.
In fact, this change does not even generalize in a trivial way to conditional navigations as used in your second example (the navigations are identified/expanded in a different visitor).
I did not yet push that changeset that includes that as a test it as I was hoping to get at least that part fixed in this PR, but maybe it's better to start by only covering the simple cases from the original issue 🤔