feat(throttle): allow customized rate limiter

[dentiny]

Rationale for this change

Hi team, for rate limit there're two metrics I care about (1) what's the blocking wait time; (2) what's the queue depth; these two metrics are important to provide insight on user workload.
I raise a related feature request here: #7312, but requires more change.
A way to unblock me for now is to allow customized rate limiter, similar to what we do at ConcurrentLimitLayer.

What changes are included in this PR?

This PR makes rate limiter generic so users could provide their own implementation; it should be a no-op change.

Are there any user-facing changes?

Current implementation SharedRateLimiter is used as default generic argument, so no API change.

AI Usage Statement

I get opus 4.6 implement the feature, with concurrent limit layer as a reference.

[tisonkun]

I'm considering that this might make the throttle layer configuration too complex and overly generalized. I’ve been thinking about how much code can actually be reused here and to what extent it should depend on governor.

Since there seems to be very little reusable code, I think two other approaches might be more appropriate:

1. Let users who want a custom rate limiter write their own layer from scratch. Currently, this throttle layer is heavily dependent on governor's functionality.
2. Follow the pattern used in observability: write a layer-throttle-base and then provide the specific implementations out of the box.

If we stick with the current approach in this PR, where we depend on governor while trying to allow custom rate limits, there isn't much reusable throttle code anyway. Instead, it just makes the codebase far too generalized.