Using Boost Asio to do async resolving

Also create a new CNetAddr() constructor from the BoostAsioToCNetAddr() method.

NOTE: This PR is related to another one (https://github.com/bitcoin/bitcoin/pull/4259).

Using boost::asio but not getaddrinfo_a() might improve the portability (I'm wondering actually...) but there are two regressions:
  1) Doesn't like the getaddrinfo_a(), the asio interface provides no timed wait/loop method, so we have to explicitly sleep when waiting for the result, which is known to be not efficient;  And refactor all places which need a dns resolving would be an obvious overkill;
  2) Doesn't like the getaddrinfo_a(), the asio::async_resolve() is implemented by calling getaddrinfo() in a newly created thread which would block on the call, so for our original purpose, to improve the net thread responsiveness, it only helps when more than one resolving jobs are issued by one thread sequentially (e.g. dnsseed thread), because only when after a resolving job (the blocking call) the thread gets its chance to response for interruption, while the getaddrinfo_a() doesn't block and can be interrupted at any time.

Base on these two issues above, I personally prefer the original PR 4259, and I'd like to submit another PR for the change of a new CNetAddr() constructor which I think is clearer than an independent method.

Signed-off-by: Huang Le <4tarhl@gmail.com>
@laanwj Yes the asio internal event loop is naturally interruptible, the problem is that it really is only when the interruption is *natural*, e.g. a SIGTERM signal from the OS.  But in our cases, where the event loop resides, say dnsseed thread, generally speaking, would have no change to receive sucn a signal, but rely on boost::thread::interrupt() call to notify it the interruption request, so we have to explicitly place one interruption point inside the event loop.

A slightly better / or cleaner manner to avoid a explicit wait loop with ios.poll() in LookupIntern() is to place one interruption point inside the handler, while using ios.run() simply.

However, no matter which way we take, as the discussion below, we still have to wait for the current outstanding call to getaddrinfo() returns, that may take quite a long time depends on the network and requested dns name, e.g. on my test box, the "dnsseed.bluematt.me" would cost about 5 minutes before return nothing.