Tracking issue for the Keyspace Service Limit

# Background

**Service Limit** will serve as the first layer boundary for resource control, ensuring that each TiDB Service (virtual cluster) in a multi-tenant (also known as multi-keyspace) environment operates within its allocated resources, preventing tasks from affecting each other, and achieving resource isolation and service stability. A Service Limit can be applied to multiple TiDB instances, and within a single Service Limit, users can continue to create different resource groups.

This is the tracking issue for the Keyspace Service Limit, which aims to:

- Implement RU/s limits for each TiDB Service to ensure fair resource usage.
- Supports multiple resource groups and sets priorities to meet business isolation and flexible scheduling.
- Provide firendly observability to ensure service experience.

# Tasks

- [x] Support resource group management at the keyspace level.
- https://github.com/tikv/pd/pull/9327
- https://github.com/tikv/pd/pull/9331
- [x] Implement the basic RU/s service limit for the resource groups within the same keyspace.
- https://github.com/tikv/pd/pull/9354
- [x] Support modify the service limit for a keyspace dynamically.
- https://github.com/tikv/pd/pull/9354
- https://github.com/tikv/pd/pull/9413
- [x] Implement a priority allocation mechanism for RU resources among different resource groups under the same service limit.
- https://github.com/tikv/pd/pull/9427
- https://github.com/tikv/pd/pull/9577
- [x] Data collection, aggregation, and observability.
- https://github.com/tikv/pd/pull/9338
- [x] Client adoption.
- https://github.com/tikv/pd/pull/9338
- https://github.com/tikv/pd/pull/9342