SQL: Resolve attributes recursively for improved subquery support (#69765)

[palesz]

Previously we did not resolve the attributes recursively which meant that if a field or expression was re-aliased multiple times (through multiple levels of subqueries), the aliases were only resolved one level down. This led to failed query translation because ReferenceAttributes were pointing to non-existing attributes during query translation.

For example the query

SELECT i AS j FROM ( SELECT int AS i FROM test) ORDER BY j

failed during translation because the OrderBy resolved the j ReferenceAttribute to another i ReferenceAttribute that was later removed by an Optimization:

OrderBy[[Order[j{r}#4,ASC,LAST]]]                                             ! OrderBy[[Order[i{r}#2,ASC,LAST]]]
\_Project[[j]]                                                                = \_Project[[j]]
  \_Project[[i]]                                                              !   \_EsRelation[test][date{f}#6, some{f}#7, some.string{f}#8, some.string..]
    \_EsRelation[test][date{f}#6, some{f}#7, some.string{f}#8, some.string..] ! 

By resolving the Attributes recursively both j{r} and i{r} will resolve to test.int{f} above:

OrderBy[[Order[test.int{f}#22,ASC,LAST]]]                                     = OrderBy[[Order[test.int{f}#22,ASC,LAST]]]
\_Project[[j]]                                                                = \_Project[[j]]
  \_Project[[i]]                                                              !   \_EsRelation[test][date{f}#6, some{f}#7, some.string{f}#8, some.string..]
    \_EsRelation[test][date{f}#6, some{f}#7, some.string{f}#8, some.string..] ! 

The scope of recursive resolution depends on how the AttributeMap is constructed and populated.

Fixes #67237

[elasticmachine]

Pinging @elastic/es-ql (Team:QL)