SQL: id on Aliases should be same if the Aliases are semantically equal

[palesz]

This problem was discovered during the investigation of the #56013 bug. Namely the following problems were discovered:

(1) SELECT 100, 100 -> success
(2) SELECT ?, ? (with params: 100, 100) -> success
(3) SELECT 100, 100 FROM test -> Unknown output attribute exception for the second 100
(4) SELECT ?, ? FROM test (params: 100, 100) -> Unknown output attribute exception for the second ?
(5) SELECT field1 as "x", field1 as "x" FROM test -> Unknown output attribute exception for the second "x"

There are two separate issues at play here:

1. Construction of AttributeMaps keeps only one of the Attributes with the same name even if the ids are different (see the AttributeMapTests in this PR). This should be fixed no matter what, we should not overwrite attributes with one another during the construction of the AttributeMap.
2. The id on the Aliases is not the same in case the Aliases have the same name and same child (meaning they are semantically equal).

For the full explanation and ways we cannot use to fix the second issue, please see: #63710 (comment)

The first issue was fixed as part of #63710 . This issue is to not forget to fix the second one (id reuse).

Take the example (3) above. The Aliases in the projections:

Today	How it should look like
100 AS 100#id_1	100 AS 100#id_1
100 AS 100#id_2	100 AS 100#id_1

[elasticmachine]

Pinging @elastic/es-ql (:Query Languages/SQL)

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)