qrest: resolve client IP from X-Forwarded-For behind trusted proxies

[ar]

The qrest-access log records the socket peer, which behind a reverse proxy (Traefik, nginx, an ingress controller) is the proxy — the real caller's address is lost.

This adds an optional trusted-proxy-cidrs property to the qrest QBean (comma-separated CIDRs, e.g. 10.42.0.0/16, 127.0.0.1/32). When set and the socket peer falls inside a trusted CIDR, the logged remote becomes the rightmost X-Forwarded-For entry not itself in the trusted set — i.e. the client as witnessed by the outermost trusted proxy.

Security properties, all covered by tests:

• Forwarded headers from an untrusted peer are never believed, so a direct caller cannot forge its logged identity with a crafted header (RestSessionTest.forwardedHeaderFromUntrustedPeerIsIgnored).
• Client-forged prefix entries in the chain are ignored; the entry appended by the trusted proxy wins.
• An all-trusted chain yields its leftmost entry (originator inside the trusted network); missing/garbage headers fall back to the socket peer.
• Address literals only — no DNS lookups; IPv6 (bracketed, CIDR) and IPv4:port forms normalized.
• A malformed CIDR throws at configuration time: a typo must fail deployment loudly, not silently trust the wrong network.

Unset property = previous behavior, byte for byte. :modules:qrest:test and javadoc green.