extend core proxy options and handling

- rework the proxy handling in init to cover more cases and work more
  thoroughly
- add -proxy6 to allow setting a separate SOCKS5 proxy to reach peers via
  IPv6
- rework proxy data-structures to allow recognition of the default proxy
  (-proxy) to give users the ability to see, which proxy (IPv6 / Tor) is
  derived from the default proxy and which was explicitly set
- extend RPC call getnetwork info

2nd commit:
- remove nameproxy, as SOCKS5 proxies support name resolution 

Most proxy-setup is now done using the new ``ProxyInit()`` function.

``bool ProxyInit(Network net, const std::string& strArg, bool fIsDefault)`` parameter description:
``net`` = network to setup proxy for (NET_IPV4, NET_IPV6 or NET_TOR)
``strArg`` = command-line argument to get values from (-proxy, -proxy6 or -onion)
``fIsDefault`` = is that proxy the default proxy (true) or a separate proxy (false)?

``bool ProxyInit(Network net, const std::string& strArg, bool fIsDefault)`` does the following:
-pre-check, if ``net`` is not limited and -no{proxy/proxy6/onion} was NOT specified
--pre-check passed: try to ``SetProxy()`` and return ``false`` on error
---pre-check passed: only for ``net == NET_TOR`` call ``SetReachable();``
---pre-check passed: return ``true``
--pre-check failed: for default proxy (``fIsDefault == true``) a failed pre-check is okay, return ``true``, otherwise ``false``

default proxy = ``-proxy``
separate IPv6 proxy = ``-proxy6``
separate Tor proxy = ``-onion``

Proxy initialisation flow (happens via ``ProxyInit()``, just the name proxy is special cased in the code):
-try to setup default IPv4 proxy
-try to setup separate Tor proxy, on failure try to setup Tor proxy via default proxy
-try to setup separate IPv6 proxy, on failure try to setup IPv6 proxy via default proxy
-try to setup default SOCKS5 name proxy

Errors initialising default proxy or IPv6/Tor proxies via default proxy lead to exit!
Let me try to explain it differently. I want to move forward to an architecture in which details of *how* the options are configured are redundant after initialization. For the core to run it only needs configuration values. Speaking on a high level a list of (option, value) tuples goes in, and you get back a running node.

Part of this is separating out the option processing from Init(). This function could also return the data that you need for the UI.

But adding a fIsDefault on the core proxyType feels like a kludge.