Ensure all SelectExpressions always have a SqlAliasManager

[roji]

The SQL alias refactoring work in 9.0 assumed that only mutable SelectExpressions need a SqlAliasManager, which is incorrect: pushdown may be called on immutable SelectExpressions later in the query pipeline (e.g. SqlNullabilityProcessor). This means that even our immutable SelectExpressions aren't really fully immutable (again a blurring of the mutability line which we need to get rid of).

In the meantime, this PR ensures that all SelectExpressions always have SqlAliasManager, regardless of whether they're (supposedly) mutable or not.

/cc @lauxjpn @ChrisJollyAU. As you've worked around this issue in 9 in your providers, and we've gotten only one user report, I'll hold back proposing this for backporting in a patch. But we can revisit that based on user feedback.

Fixes #35507

[ChrisJollyAU]

Quick eyeball looks good. Will probably have a closer look during the week.

Thats fine to keep it to 10.0. It's a rather specific bug that doesn't pop up much. To be honest I actually think those writing ef core providers are the most likely to bump into this especially if they need to do some pushdowns because of any modifications for postprocessing/optimizing.

[roji]

Thanks @ChrisJollyAU, a review would definitely be appreciated. Yeah, I wouldn't necessarily have even worked on this at this point if it hadn't been for the user-visible regression it causes (#35507).

[ocdi]

As the user who is reported this bug, this is a blocker for us upgrading to 9.x. Once this has been merged to main, is there a way we can get this into a 9.x build?

[roji]

@ocdi the bar for patching is usually pretty high, and we haven't got any other reports of users hitting this yet - but I'll discuss with the team.

[roji]

Design decision: as this is a non-trivial and not easily quirkable fix, we'll hold off patching this for now, until we get at least one additional user report. At that point we can consider backporting this fix or a more targeted hack.