Introduce whitelisted peers.

This adds a `-whitelist` option to specify subnet ranges from which peers that connect are whitelisted. In addition, there is a `-whitebind` option which works like `-bind`, except peers connecting to it are also whitelisted (allowing a separate listen port for trusted connections).

Being whitelisted has two effects (for now):
* They are immune to DoS banning.
* Transactions they broadcast (which are valid) are always relayed, even if they were already in the mempool. This means that a node can function as a gateway for a local network, and that rebroadcasts from the local network will work as expected.

Whitelisting replaces the magic exemption localhost had for DoS banning, which implies hidden service connects (from a localhost Tor node) were incorrectly immune to DoS banning as well. This old behaviour is removed for that reason, but can be restored using `-whitelist=127.0.0.1` or `-whitelist=::1`. `-whitebind` is safer to use in case non-trusted localhost connections are expected (like hidden services).

This is a partial replacement for #3403 (but does not add RPC commands to make whitelisting dynamic). Also, hhitelisting becomes a boolean property of a peer here (set at connect time), rather than defined by a set of netmasks. This means we don't need to match the address on every invocation of a relay.
Why? This will cause any misbehaviour that is equal to or greater than the threshold set to cause the node to never be disconnected!