evhttpd implementation

• *Replace usage of boost::asio with libevent2*.

boost::asio is not part of C++11, so unlike other boost there is no
forwards-compatibility reason to stick with it. Together with #4738 (convert
json_spirit to UniValue), this rids Bitcoin Core of the worst offenders with
regard to compile-time slowness.

• *Replace spit-and-duct-tape http server with evhttp*. Front-end http handling

is handled by libevent, a work queue (with configurable depth and parallelism)
is used to handle application requests.

• *Wrap HTTP request in C++ class*; this makes the application code mostly

HTTP-server-neutral

• *Refactor RPC to move all http-specific code to a separate file*.

Theoreticaly this can allow building without HTTP server but with another RPC
backend, e.g. Qt's debug console (currently not implemented) or future RPC
mechanisms people may want to use.

• *HTTP dispatch mechanism*; services (e.g., RPC, REST) register which URL

paths they want to handle.

By using a proven, high-performance asynchronous networking library (also used
by Tor) and HTTP server, problems such as #5674, #5655, #344 should be avoided.

What works? bitcoind, bitcoin-cli, bitcoin-qt. Unit tests and RPC/REST tests
pass. The aim for now is everything but SSL support.

Configuration options:

• -rpcthreads: repurposed as "number of work handler threads". Still

defaults to 4.

• -rpcworkqueue: maximum depth of work queue. When this is reached, new

requests will return a 500 Internal Error.

• -rpctimeout: inactivity time, in seconds, after which to disconnect a

client.

• -debug=http: low-level http activity logging