Improvement ideas / backlog for single shard tables / tenant schema tables

Performance improvements that would be useful for **both** single-shard tables and tenant-schema tables:
- [ ] Fix prepared statements / plan cache for single-shard tables.

DDL improvements that could provide a better user experience when creating / altering **tenant-schema tables**:
- The following cannot be used to create a tenant table:
- [ ] CREATE TABLE tenant_546.users OF TYPE ..
- [ ] CREATE SCHEMA tenant_546 CREATE TABLE users ..

SQL / planner improvements that would be useful for **both** single-shard tables and tenant-schema tables:
- [ ] **(High priority) (Medium)** Support INSERT with sublinks.
- [ ] **(High priority) (Medium)** Support UPDATE with volatile functions.
- [ ] "INSERT INTO single_shard_table SELECT .." cannot go through repartitioned insert-select.
Tough I'm not sure if this is easily doable because the code-path essentially expect the target table to have shard-key.
- [ ] Planner unnecessarily decides that an outer join of the FORM \< recurring_rel LEFT JOIN single_shard_table \> would result in recurring tuples but indeed this is not the case for single-shard tables, hence we unnecessarily go through recursive planner for such joins.
- [ ] Support non-router MERGE with single-shard tables with / without distributed tables.

UX Improvements for **tenant-schema tables** that we might want to do depending on user feedback:
- [ ] Allow having usual distributed / reference tables etc. in tenant schemas, via alter_distributed_table() / create_distributed_table() / create_distributed_table_concurrently() / create_reference_table() / undistribute_table() (somewhat bigger item).
- [ ] Allow colocating tenant schemas.
- [x] Support routing in pgbouncer based on search_path.
- [ ] Enable foreign keys _from_ reference tables _to_ tenant tables without on update/delete cascade (should be fairly easy).

Technical / non-user-facing improvements for **tenant-schema tables**:
- [ ] Generalize Citus local tables into a single-shard group that’s pinned to the coordinator (somewhat bigger item).
- [ ] Evaluate if it's possible to combine ConvertNewTableIfNecessary() logic with Postprocess_CreateTable.

Operation improvements that are **only about the single-shard tables** (i.e., those are are not associated with a tenant schema):
- [ ] create_distributed_table_concurrently() doesn't support creating a single shard table.
- [ ] alter_distributed_table() doesn't support altering a single-shard table.
- [ ] alter_distributed_table() doesn't support colocating a random table with a single-shard table.
- [ ] split_shards() could allow splitting shard of a single shard table by accepting a distribution column argument.
Alternatively, allowing create_distributed_table_concurrently() to accept a single-shard table would help with the same scenario without requiring a syntax change.