ssmapi: Extend SSM API to all multi-user inbounds

[alireza0]

Motivation

The SSM API service currently manages users only for multi-user Shadowsocks
inbounds. Every other multi-user inbound requires a full instance restart to
apply a user change, which drops all active connections — even though the
underlying services (transport/trojan, sing-vmess, sing-quic, sing-anytls)
already support live user replacement, and the SSM API service itself is
written against a generic adapter.ManagedSSMServer interface rather than
anything Shadowsocks-specific.

This PR implements adapter.ManagedSSMServer on the remaining inbounds whose
user model fits the SSM credential model (one user name + one key), so they
can be listed in the ssm-api servers map and managed at runtime:

HTTP, Mixed, SOCKS, Naive, Trojan, VMess, AnyTLS, Hysteria, and Hysteria2.

What's changed

• Each inbound gains UpdateUsers/SetTracker, mirroring the existing
  Shadowsocks MultiInbound implementation, and wraps authenticated
  connections with the SSM tracker for per-user traffic accounting.
• Trojan/VMess/AnyTLS/Hysteria/Hysteria2 delegate to the existing
  Service.UpdateUsers of their protocol libraries; HTTP/Mixed/SOCKS/Naive
  rebuild their auth.Authenticator.
• User name lookups by index are now bounds-checked, since the user list can
  shrink while long-lived (QUIC) connections still resolve names with an old
  index.
• No new configuration surface: unlike Shadowsocks, these inbounds have no
  single-user/multi-user service split, so the managed flag is not needed —
  referencing the inbound from ssm-api servers is sufficient.
• Documentation updated (en/zh).

Scope notes

• VMess: the SSM user key maps to the UUID; managed users use alterId 0.
• VLESS and TUIC are intentionally excluded: their users cannot be expressed
  as a single credential (flow, and uuid + password respectively).

Verification

Manually exercised against a running instance: users added/updated/deleted
via the REST endpoints take effect immediately on Trojan and Mixed inbounds
(new credentials authenticate, removed/replaced credentials are rejected),
and per-user traffic counters appear in /server/v1/stats.