Fix for #6055

Alias2 references the first node in the select list, which is alias1. alias1 references the 0th index in the select list, which is cte.a. The issue is that don't keep track of what alias's we have visited when binding a where clause. The same issue happens in the following SQL query
select i as b, b as c, c as d, d as e from a where e > 5;

The solution is the following. Instead of keeping track if we are in an alias or not, we keep track of what indexes in our select list we end up referencing when binding aliases. If we follow a rabbit hole of alias binding, we will eventually be able to detect a self-referencing alias, or we will be able to find the desired column to bind to.

This doesn't happen in the SelectBinder because we have access to the BoundSelectNode instance in the select binder (i.e node.select_list. We can then just copy the node in the select list the alias refers to. We are assured this node is bound because it comes earlier in the select list. A where binder doesn't have access to a BoundSelectNode.