Consider making multi-tenant sharding explicit

We currently require users to add a `tenant_id` filters to all their queries, which significantly complicates the migration process. The client needs to specify the `tenant_id` in order to efficiently determine which shard(s) to use. However, that does not mean the tenant_id needs to always be specified in queries themselves.

We could introduce an explicit notion of a tenant that can be set before running a query. A table could
be distributed by tenant even without having it as a column.

A possible implementation could then be to use a GUC to set the tenant.

```
CREATE TABLE hits (
page_id int,
ip inet,
hit_time timestamptz default now()
);
SELECT distribute_by_tenant('hits');

BEGIN;
SET citus.tenant TO 'citusdata.com';
INSERT INTO hits (page_id, ip) VALUES (3, '123.0.0.1');
END;
```

This means the client needs some specific logic to set the GUC at the start of the transaction, but it needs no other logic for migration or application conversion. An advantage is that the `citus.tenant` GUC can be coupled with a PostgreSQL role.

An alternative is to preserve the `tenant_id` column, but always fill it in based on the value of the GUC.

```
CREATE TABLE hits (
tenant_id int not null,
page_id int,
ip inet,
hit_time timestamptz default now()
);
SELECT distribute_by_tenant('hits', 'tenant_id');

BEGIN;
SET citus.tenant TO 'citusdata.com';
INSERT INTO hits (page_id, ip) VALUES (3, '123.0.0.1');
END;
```

That way, commands like COPY and multi-shard SELECT can still work as expected.