Rethink client IP headers

We currently set spin-client-addr to the incoming client's <ip>:<src port>, but it is ambiguous whether this is the closest hop on the network (often a reverse proxy) or some previous hop in the proxy chain (which could be the original client IP). I suggest that we update the docs to state that this header is optional and that when present it only holds the address of the "closest hop".

Separately, we might want to think about documenting a "Spin standard" way to expose trusted forwarding information to guests. This would probably involve some http trigger config like e.g. SPIN_HTTP_TRUSTED_CLIENT_IP_HEADER=x-forwarded-for where the operator pinky swears that the header is valid.

When enabled, this trusted information would be exposed to guests; a couple of options for that:

• a new e.g. spin-trusted-client-ip header that is only set if the info is available
• (slightly more "standardsy"): use the forwarded header and apply some transformation so that trusted and untrusted entries can be distinguished, for example by (ab)using the by field or by blatantly disregarding the RFC and introducing our own parameter without registering it with IANA.

We should document whatever we decide here, even if it only ends up being a recommendedation.

Start by reviewing the existing documentation for the optional spin-client-addr header and how it describes the closest hop. Then resolve whether Spin should define a trusted forwarding mechanism and document the chosen header or recommendation, including how trusted and untrusted information are distinguished.