feat: add URMA transport support

[zchuango]

What problem does this PR solve?

Issue Number: Related to #3401

Problem Summary:

brpc does not currently provide a remote-memory transport based on the UMDK
URMA API.

This PR adds URMA (Unified Remote Memory Access) as an optional transport in
the existing Transport framework. TCP is used for connection establishment
and URMA capability/resource negotiation. After both peers successfully
negotiate URMA support, the data path switches to URMA. When URMA is
unavailable or negotiation does not succeed, the connection falls back to TCP.

The initial implementation supports the baidu_std protocol only and is
disabled by default.

What is changed and the side effects?

Changed:

• Add SOCKET_MODE_URMA and UrmaTransport, and integrate them with the
  existing transport, socket, and message-processing framework.
• Add UrmaEndpoint for URMA resource management, SEND/RECV processing,
  completion handling, and credit-based flow control.
• Add TCP-based URMA capability and resource negotiation, including v2 binary
  and v3 protobuf handshake formats, with TCP fallback.
• Add a registered buffer pool for IOBuf blocks and APIs for explicit user
  memory registration.
• Support completion-event mode and optional busy-polling mode.
• Support the UMDK bonding extension when the corresponding provider extension
  is available.
• Add optional URMA build integration for CMake, Make, and Bazel, together with
  a link-time URMA mock for build and test environments without liburma or
  URMA hardware.
• Add URMA unit tests, English and Chinese documentation, and an
  urma_performance example.

Side effects:

• Performance effects:

  • URMA is optional and disabled by default. Existing socket modes and their
    default behavior remain unchanged.
  • Enabling URMA maps and registers a configurable IOBuf buffer pool. The
    default configuration is 65,536 buffers of 8 KiB each (512 MiB in total).
  • Busy-polling mode may increase CPU usage because completion pollers
    actively poll the JFC.
  • URMA performance depends on the provider, driver, hardware, and polling
    configuration. This PR does not claim a specific hardware performance
    improvement.

• Breaking backward compatibility:

  • No intended breaking changes.
  • SOCKET_MODE_URMA and the URMA memory-registration APIs are additive.
    Existing socket modes and their default behavior remain unchanged.

---

Check List:

• Please make sure your changes are compilable.
• When providing us with a new feature, it is best to add related tests.
• Please follow Contributor Covenant Code of Conduct.