Use connection pools for _changes requests

In high-throughput scenarios the process of setting up new HTTPS connections can
bottleneck replication performance. The #htttpdb.httpc_pool construct alleviates
most of this pain, but _changes requests don't use them.

The decision to not use connection pools for _changes requests is an old one. As
far as I can discern it is/was related to the use of HTTP pipelining in the
original implementation of couch_replicator. Pipelining is long-gone, but
_changes requests still set up their own connections.

This patch reconfigures replications to use the available connection pool for
_changes requests, along with associated cleanup of related code now rendered
unnecessary.
Update handle_changes function names
couch_replicator: add replication using changes in a view

Instead of a database, the replicator can now filter the documents using
a view index. All documents having a key emitted in the view can be
replicated.

View parameters can be used. Which means that you can replicate results
corresponding to a key in a view or a range.

Conflicts:
	src/couch_replicator.erl
	src/couch_replicator_api_wrap.erl
don't replicate removed document in a view changes

Conflicts:
	src/couch_replicator.erl
	src/couch_replicator_api_wrap.erl
fix view changes with multiple keys

Conflicts:
	rebar.config
	src/couch_replicator.erl
remove old rcouch code