brpc is built on Protobuf Generic Services, which are deprecated

Hello, I work on Protocol Buffers at Google.

As part of our overall efforts to reduce tech debt in our code, we would like to remove [generic services](https://github.com/protocolbuffers/protobuf/blob/7bb6178325f4b4ff6f7ed8697c69d3f67e747034/src/google/protobuf/descriptor.proto#L503-L517) from our code generator. These have been marked as deprecated since 2010, both in [the docs](https://protobuf.dev/programming-guides/proto3/#options) and in several places in the code ([descriptor.proto](https://github.com/protocolbuffers/protobuf/blob/7bb6178325f4b4ff6f7ed8697c69d3f67e747034/src/google/protobuf/descriptor.proto#L509-L512), [service.h](https://github.com/protocolbuffers/protobuf/blob/7bb6178325f4b4ff6f7ed8697c69d3f67e747034/src/google/protobuf/service.h#L12-L19), [service.py](https://github.com/protocolbuffers/protobuf/blob/7b7a80eae4f46cca5d3a2781b4412ef769856cdb/python/google/protobuf/service.py#L31-L41), etc.).

We noticed that bRPC is built on generic services. Because these APIs are exposed directly to your users, a sudden removal on our end would cause significant disruption to the bRPC ecosystem. We want to avoid that and work together to manage this transition as smoothly as possible.

To move forward, the sustainable path is for bRPC to transition to its own custom code generator (a `protoc` plugin) to generate these service APIs, rather than relying on the built-in generic services option in `protoc`. This is the standard approach modern RPC frameworks (like gRPC) use to generate their stubs.

We want to give your team ample runway to design, implement, and distribute this migration.

- **Timeline:** We are targeting **Q1 2028** to disable the `xx_generic_services` options (making them into no-ops). Prior to this, we will begin emitting warnings and possibly require that a special codegen flag be set to continue using generic services.
- **Our Support:** We are happy to provide guidance on how to structure a custom generator plugin, share references from how other frameworks achieved this, or review migration designs to make this process easier for you.

Please let us know your thoughts on this timeline and how we can best support the Apache bRPC community during this transition.

Start by reviewing how brpc currently relies on Protobuf Generic Services, then read the referenced descriptor.proto, service.h, and service.py locations to understand the deprecated APIs. The work is done when brpc has a custom protoc plugin generating its service APIs and a migration and distribution path is defined for users.

Written by the indexing model from the issue text.