Introduced finalizeAndExecute to the AbstractSqlWalker, unified SingleStatementExecutor

[dciprian-petrisor]

Fixes #11112

I've taken the approach suggested by @beberlei in #11188 (comment)

This essentially delays setting limit/offset and locking on the SQL to the finalizeAndExecute function, which accepts the Query object as a parameter.

I also unified the SingleSelectExecutor and SingleTableDeleteUpdateExecutor into a single class: SingleStatementExecutor since it was mostly the same implementation.

The Query::getQueryCacheId was changed to no longer care about the firstResult/maxResults parameters, since using them in the cache key results in different cache keys for what is essentially the same query.

I had to expose the selectedClasses field from the SqlWalker since it is used to determine if optimistic locking is possible.

Please let me know if this is an acceptable solution.

If so, I will gladly introduce tests/make any other necessary adjustments, per maintaniers' instructions.

Thank you!

[dciprian-petrisor]

One thing I realize now: the change to getQueryCacheId is backwards incompatible.
The limit/offset parameters have to be removed for this change to fix the original issue, otherwise there will be a cache miss no matter when we inject them into the sql.

I'm not sure how to proceed here, please guide me if this change needs to target a different branch or we can expose this behind some kind of configuration option/flag.

Thank you!