SQL: `id` on `Alias`es should be same if the `Alias`es are semantically equal

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 `AttributeMap`s keeps only one of the `Attribute`s with the same name even if the `id`s 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 `Alias`es is not the same in case the `Alias`es 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: https://github.com/elastic/elasticsearch/pull/63710#issuecomment-721236168

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 `Alias`es 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 |

Start by reading the explanation and constraints linked from #63710, then inspect the AttributeMapTests mentioned in the issue and reproduce the SQL examples, especially duplicate projections from (3). Done means semantically equal Aliases reuse the same id while distinct attributes are not overwritten during AttributeMap construction.

Written by the indexing model from the issue text.