Proposal: Deprecate circuit breakers in favor of new extension type (or upstream filters)

This issue proposes phasing out [circuit breakers](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/cluster/v3/circuit_breaker.proto) in favor of using extensions that accomplish the same thing. The legacy circuit breaker configuration in the cluster proto can be replaced by extensions--either a new "circuit breaker extension" category or upstream filters that would serve the same purpose.

### Rationale
The need for this architectural change became apparent during the implementation of Gateway API conformance for retry budgets in #44147.

In that discussion, Envoy's built-in circuit breaker and retry budget implementations operate on a "level-triggered" model and this caused friction. In this model, enforcement is state-based, and the decision to allow retries depends on the number of requests currently in an active or outstanding state at any given point in time.

New requirements like the `budget_interval` for Gateway API conformance require an "edge-triggered" model, which counts the number of request *start events* that occur within a specific time window.

Attempting to bolt this edge-triggered behavior onto the existing level-triggered configuration built into the cluster proto creates a fundamental conflict and confusing semantics for users. Moving circuit breakers to an extensible model is the cleanest way to support these kinds divergent paradigms moving forward.

Here are other examples of circuit breaker changes that would be made feasible if circuit breakers were implemented as pluggable extensions:
- https://github.com/envoyproxy/envoy/issues/14550
- https://github.com/envoyproxy/envoy/issues/38241
- https://github.com/envoyproxy/envoy/pull/43355

There are also a handful of existing filters that would make sense as circuit breaker extensions, such as [admission control](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/admission_control_filter) and [adaptive concurrency](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/adaptive_concurrency_filter).

### Approach to Implementation
Creating a new circuit breaker extension type is a non-trivial amount of work, so upstream filters might be the way to go here. Whichever one we land on, the high-level approach will be:

1. **Define the Extension Interface:** Create a new extension point API for circuit breakers or implement new "concurrency control" upstream filters.
2. **Implement the Legacy Behavior:** Port the existing built-in circuit breaker functionality into a default extension to ensure we maintain backward compatibility.

Once the new extensions are fully implemented and available, we would begin the deprecation process for the built-in circuit breaker fields. To ensure a smooth transition for the community, we would provide a generous deprecation window of at least a year before removing the old fields.

---

Let me know your thoughts.