fix: resolve aliased catalogs

[universalmind303]

closes #2779

Note for Reviewers:

There isn't a real good way that I know of to add a test for this, so i will just share the steps I took to manually test it.

1. go to console.glaredb.com
2. create a view in there: create view "my_view" as select 1;
3. connect to cloud via local

> just run local
> \open glaredb://<USER>:<PASS>@o_xTz3cuY.remote.glaredb.com:6443/quiet_frog
Connected to Cloud deployment (TLS enabled): quiet_frog
> select * from "quiet_frog"."public"."my_view";
┌──────────┐
│ Int64(1) │
│       ── │
│    Int64 │
╞══════════╡
│        1 │
└──────────┘

it also works the other way around. Previously a create statement create view quiet_frog.public.my_view_2 would save it to the "default" db, now it properly saves it under the alias name

> create view "quiet_frog"."public"."my_view_2" as select 2;
View created
> select * from my_view_2;
┌──────────┐
│ Int64(2) │
│       ── │
│    Int64 │
╞══════════╡
│        2 │
└──────────┘
> select * from "quiet_frog"."public"."my_view_2";
┌──────────┐
│ Int64(2) │
│       ── │
│    Int64 │
╞══════════╡
│        2 │
└──────────┘
>

[vrongmeal]

Should we also restrict creating an external database with the same name as catalog alias? Seems like something that could lead to conflicts/issues with not being able to access an external source.