Remove notion of header priority

As I was drumming up docs, I realized that it probably doesn't make
sense to prioritize certain headers, even if configurable. I'd merely
inherited this behavior from the (tacit) way other code bases I was
reading handled multiple types of headers.

Before, RemoteIp would loop through each configured header. The first
one with a match would overwrite the remote_ip. However, in a
multi-proxy setup, it could be that you have proxy 1 that forwards the
request using (say) Forwarded for= and proxy 2 that adds
X-Forwarded-For. By the time it reaches the app, the old RemoteIp code
would've either chosen to look at *only* the Forwarded header or *only*
the X-Forwarded-For header, depending on which you put first in the
:headers option.

It makes more sense to me to consider *all* allowed headers "at once",
but in the same order as they are sorted in the HTTP request. It's the
only real source of truth we have, after all. It's worth noting, though,
that this *could* still be screwed up by header amending. Consider:

• request starts from IP 1.1.1.1
• proxy 1 with IP 2.2.2.2 adds Forwarded for=1.1.1.1
• proxy 2 with IP 3.3.3.3 adds X-Forwarded-For 2.2.2.2
• proxy 3 with IP 4.4.4.4 amends Forwarded to say Forwarded for=1.1.1.1,3.3.3.3
• RemoteIp processes request from 4.4.4.4 with the "first to last" list of forwarded IPs [{1, 1, 1, 1}, {3, 3, 3, 3}, {2, 2, 2, 2}], even though the ACTUAL order was [{1, 1, 1, 1}, {2, 2, 2, 2}, {3, 3, 3, 3}]

The way around this issue is to configure both 2.2.2.2 & 3.3.3.3 as
known proxies, in which case both of those IPs will be ignored, so their
order doesn't really matter (1.1.1.1 will still be "to the left" of
them).