**Describe the unexpected behaviour**

The column resolution seems to resolve an alias to the wrong column when there is a left join in the query.

**How to reproduce**
* Which ClickHouse server version to use: `20.3.12.112`
* Which interface to use, if matters: HTTP Interface (but should not matter)

Please run the following queries:
```sql
-- Tables
CREATE TABLE default.tableConversion (
	conversionId String,
	value Nullable(Double)
) ENGINE = Log();

CREATE TABLE default.tableClick (
	clickId String,
	conversionId String,
	value Nullable(Double)
) ENGINE = Log();

CREATE TABLE default.leftjoin (
	id String
) ENGINE = Log();

-- Values
INSERT INTO default.tableConversion(conversionId, value) VALUES ('Conversion 1', 1);
INSERT INTO default.tableClick(clickId, conversionId, value) VALUES ('Click 1', 'Conversion 1', 14);
INSERT INTO default.tableClick(clickId, conversionId, value) VALUES ('Click 2', 'Conversion 1', 15);
INSERT INTO default.tableClick(clickId, conversionId, value) VALUES ('Click 3', 'Conversion 1', 16);

-- Query
SELECT
	conversion.conversionId as myConversionId,
	click.clickId as myClickId,
	click.myValue as myValue
FROM (
	SELECT conversionId, value as myValue
	FROM default.tableConversion
) as conversion
INNER JOIN (
	SELECT clickId, conversionId, value as myValue
	FROM default.tableClick
) as click ON click.conversionId = conversion.conversionId
LEFT JOIN (
	SELECT * FROM default.leftjoin
) as dummy on (dummy.id = conversion.conversionId)
```

**Expected behavior**
The values in the `myValue` column should be 14, 15 and 16.

**Actual behaviour**
The values in the `myValue` column is 1.

This means, that the colum `click.myValue as myValue` gets resolved as `conversion.myValue`. Please notice that the source table has been changed!

**Additional context**

The behaviour is only visible when there is a `LEFT JOIN` in the Query. Referencing the `leftjoin` table in the `SELECT` statement does not change the result. **Leaving the `LEFT JOIN` out of the query makes it return the correct results.**

/** List of settings: type, name, default value, description, flags
      *
      * This looks rather unconvenient. It is done that way to avoid repeating settings in different places.
      * Note: as an alternative, we could implement settings to be completely dynamic in form of map: String -> Field,
      *  but we are not going to do it, because settings is used everywhere as static struct fields.
      *
      * `flags` can be either 0 or IMPORTANT.
      * A setting is "IMPORTANT" if it affects the results of queries and can't be ignored by older versions.
      */
#define COMMON_SETTINGS(M)                                            \
    M(SettingUInt64, min_compress_block_size, 65536, "The actual size of the block to compress, if the uncompressed data less than max_compress_block_size is no less than this value and no less than the volume of data for one mark.", 0) \
    M(SettingUInt64, max_compress_block_size, 1048576, "The maximum size of blocks of uncompressed data before compressing for writing to a table.", 0) \
    M(SettingUInt64, max_block_size, DEFAULT_BLOCK_SIZE, "Maximum block size for reading", 0) \
    M(SettingUInt64, max_insert_block_size, DEFAULT_INSERT_BLOCK_SIZE, "The maximum block size for insertion, if we control the creation of blocks for insertion.", 0) \
    M(SettingUInt64, min_insert_block_size_rows, DEFAULT_INSERT_BLOCK_SIZE, "Squash blocks passed to INSERT query to specified size in rows, if blocks are not big enough.", 0) \
    M(SettingUInt64, min_insert_block_size_bytes, (DEFAULT_INSERT_BLOCK_SIZE * 256), "Squash blocks passed to INSERT query to specified size in bytes, if blocks are not big enough.", 0) \
    M(SettingUInt64, min_insert_block_size_rows_for_materialized_views, 0, "Like min_insert_block_size_rows, but applied only during pushing to MATERIALIZED VIEW (default: min_insert_block_size_rows)", 0) \
    M(SettingUInt64, min_insert_block_size_bytes_for_materialized_views, 0, "Like min_insert_block_size_bytes, but applied only during pushing to MATERIALIZED VIEW (default: min_insert_block_size_bytes)", 0) \
    M(SettingUInt64, max_joined_block_size_rows, DEFAULT_BLOCK_SIZE, "Maximum block size for JOIN result (if join algorithm supports it). 0 means unlimited.", 0) \
    M(SettingUInt64, max_insert_threads, 0, "The maximum number of threads to execute the INSERT SELECT query. Values 0 or 1 means that INSERT SELECT is not run in parallel. Higher values will lead to higher memory usage. Parallel INSERT SELECT has effect only if the SELECT part is run on parallel, see 'max_threads' setting.", 0) \
    M(SettingUInt64, max_final_threads, 16, "The maximum number of threads to read from table with FINAL.", 0) \
    M(SettingMaxThreads, max_threads, 0, "The maximum number of threads to execute the request. By default, it is determined automatically.", 0) \
    M(SettingMaxThreads, max_alter_threads, 0, "The maximum number of threads to execute the ALTER requests. By default, it is determined automatically.", 0) \
    M(SettingUInt64, max_read_buffer_size, DBMS_DEFAULT_BUFFER_SIZE, "The maximum size of the buffer to read from the filesystem.", 0) \
    M(SettingUInt64, max_distributed_connections, 1024, "The maximum number of connections for distributed processing of one query (should be greater than max_threads).", 0) \
    M(SettingUInt64, max_query_size, 262144, "Which part of the query can be read into RAM for parsing (the remaining data for INSERT, if any, is read later)", 0) \
    M(SettingUInt64, interactive_delay, 100000, "The interval in microseconds to check if the request is cancelled, and to send progress info.", 0) \
    M(SettingSeconds, connect_timeout, DBMS_DEFAULT_CONNECT_TIMEOUT_SEC, "Connection timeout if there are no replicas.", 0) \