Fix ESCAPE clause for Azure Synapse.

[cincuranet]

Fixes #33555

[roji]

This looks like it just omits the ESCAPE clause for Synapse; doesn't that mean that bad results would be returned? In other words, the ESCAPE isn't needed to get the correct results, why do we have it there in the first place?

I think the fix needed here is to vary our translation for Synapse, translating to correct (but inferior) SQL which doesn't depend on LIKE+ESCAPE. You can look at pre-8.0 EF to see what we were doing (as this is a regression in 8.0).

[cincuranet]

I took the previous translation and put it into TryTranslateStartsEndsWithContainsOldStyle (and downstream). No major refactoring or anything like that, because I don't want to introduce bugs.

[roji]

If I look at the existing TryTranslateStartsEndsWithContains, doesn't the default case ("The pattern is a column or a complex expression") already contain exactly the logic we need? Any particular reason to duplicate the entire function for Synapse, rather than just jump to that case whenever we're on Synapse and would need to use ESCAPE? I don't really see any risk problem here...

[cincuranet]

Now it's using the code from the original default case, but also has some optimizations based on the fact that for a constant pattern we can omit some checks.

[roji]

LGTM, see mostly nits

[cincuranet]

/backport to release/9.0