sql: cannot create RBR table with explicit region in hash-sharded index

(Thanks to @sheaffej for finding this!)

Combining hash-sharding and regional by row locality should mostly work already, especially after #94436. For example, this works:

```sql
CREATE TABLE ab (
region crdb_internal_region NOT NULL,
a INT NOT NULL,
b INT,
PRIMARY KEY (a) USING HASH,
INDEX (b) USING HASH
) LOCALITY REGIONAL BY ROW AS region;
SHOW CREATE TABLE ab;
```

Looking at the descriptor we can see that the key columns for the primary index and secondary index are (region, crdb_internal_a_shard_16, a) and (region, crdb_internal_b_shard_16, b), respectively, which is what I would expect.

(I think this is the only ordering of columns that makes sense.)

But, if we try to make the region column explicit in both indexes, we cannot create the table:

```sql
CREATE TABLE ab2 (
region crdb_internal_region NOT NULL,
a INT NOT NULL,
b INT,
PRIMARY KEY (region, a) USING HASH,
INDEX (region, b) USING HASH
) LOCALITY REGIONAL BY ROW AS region;
-- ERROR: hash sharded indexes cannot include implicit partitioning columns from "PARTITION ALL BY" or "LOCALITY REGIONAL BY ROW"
```

We can't do it this way, either:

```sql
CREATE TABLE ab2 (
region crdb_internal_region NOT NULL,
a INT NOT NULL,
b INT,
PRIMARY KEY (region, a) USING HASH,
INDEX (region, b) USING HASH
);
ALTER TABLE ab2 SET LOCALITY REGIONAL BY ROW AS region;
-- ERROR: relation "ab2" (108): index "new_primary_key" contains duplicate column "region"
```

Nor this way:

```sql
CREATE TABLE ab3 (
region crdb_internal_region NOT NULL,
a INT NOT NULL,
b INT,
PRIMARY KEY (region, a),
INDEX (region, b)
) LOCALITY REGIONAL BY ROW AS region;
ALTER TABLE ab3 ALTER PRIMARY KEY USING COLUMNS (region, a) USING HASH;
-- ERROR: hash sharded indexes cannot include implicit partitioning columns from "PARTITION ALL BY" or "LOCALITY REGIONAL BY ROW"
DROP INDEX ab3_region_b_idx;
CREATE INDEX ON ab3 (region, b) USING HASH;
-- ERROR: superfluous data in encoded value
```

Plus, this doesn't quite make sense, because we don't want the region column to be included in the hash.

I think what we want is the same ordering of columns as in the first example, (region, shard, rest of the columns), but with region as an explicit key column instead of an implicit key column, so that the uniqueness checks are skipped.

Jira issue: CRDB-50890

Epic CRDB-45396

Start by reproducing the CREATE TABLE and ALTER TABLE examples in the issue, then compare the index descriptors with SHOW CREATE TABLE. Trace the handling of explicit region columns, hash-sharded indexes, and REGIONAL BY ROW definitions. Done means the supported definition produces the expected (region, shard, remaining columns) ordering without hashing the region or raising the reported errors.

Written by the indexing model from the issue text.