Support pre-splitting secondary index regions during CREATE TABLE with PRE_SPLIT_REGIONS

## Feature Request

**Is your feature request related to a problem? Please describe:**

When a table is created with `SHARD_ROW_ID_BITS` (or `AUTO_RANDOM`) and `PRE_SPLIT_REGIONS`, TiDB pre-splits only the row-data regions. Secondary indexes are not pre-split in the same way, so index reads/writes can still concentrate on one/few index regions.

This becomes a practical problem for reads/writes hotspot workloads right after table creation:
- row writes are scattered by `PRE_SPLIT_REGIONS`
- index writes are still concentrated
- hot index regions appear easily and can become the bottleneck

A simple example is:

```sql
CREATE TABLE t (
a BIGINT,
b BIGINT,
KEY idx_a(a)
) SHARD_ROW_ID_BITS = 4 PRE_SPLIT_REGIONS = 2;
```

According to the current documented behavior, this creates `4 + 1` regions:
- `4` regions for row data
- only `1` region for the index

So even though row writes are distributed, index writes can still be hot.

**Describe the feature you'd like:**

I’d like TiDB to enhance `CREATE TABLE` pre-splitting so that index regions can also be scattered during table creation, ideally aligned with the row pre-splitting behavior when `PRE_SPLIT_REGIONS` is specified.

Possible directions:
1. Automatically pre-split secondary index regions when `PRE_SPLIT_REGIONS` is enabled.
2. Provide an explicit option to enable and control index pre-splitting during `CREATE TABLE`.
3. Reuse the existing split/scatter flow so index regions are also scattered before the write burst begins.

From a user perspective, the goal is that `PRE_SPLIT_REGIONS` should not only protect row data from hotspots, but also reduce the chance of immediate index hotspots after table creation.

**Describe alternatives you've considered:**

1. Run `SPLIT TABLE ... INDEX ...` manually after `CREATE TABLE`.
- This works only when users already know the index value ranges.
- It adds operational complexity and is less convenient than doing it directly in `CREATE TABLE`.

2. Rely on automatic Region split after data is written.
- This is too late for the initial write burst, where hotspots already happen.

3. Use only row pre-splitting.
- This helps row writes, but does not address index hotspots sufficiently.

If fully mirroring row-style pre-splitting for all index types is not feasible, an explicit index pre-split option in `CREATE TABLE` would still be very valuable.

**Teachability, Documentation, Adoption, Migration Strategy:**

This feature would be easy to explain because users already understand `PRE_SPLIT_REGIONS` as "scatter the table before heavy writes".
It would be more intuitive if indexes could participate in that behavior as well, or if TiDB provided an explicit `CREATE TABLE` option for index pre-splitting.

Documentation should clarify:
- current row-data vs index pre-split behavior
- which index types are supported
- whether the behavior is automatic or opt-in
- interaction with `tidb_scatter_region`

### Current behavior in code

The current create-table pre-split flow goes through DDL pre-split/scatter logic, and row pre-splitting is derived from shard bits / pre-split regions. However, index splitting currently only separates index keyspaces by index prefix, instead of creating row-like pre-split regions for each index.

So the current behavior appears intentional/implemented, but it leaves a gap for write-heavy index workloads.

### References

- TiDB documentation on `SPLIT REGION` / `PRE_SPLIT_REGIONS`: https://docs.pingcap.com/tidb/stable/sql-statement-split-region/
- DDL executor pre-split entry: https://github.com/pingcap/tidb/blob/master/pkg/ddl/executor.go
- Region split logic: https://github.com/pingcap/tidb/blob/master/pkg/ddl/split_region.go