(#3146) Adding pull replication performance tests

perf.basics.js -
 - Moved createDocId to common-utils
 - Added the test pull-replication-perf-skimdb, turned off by default (set to 0 iterations), which will download from @nolanlawson 's copy of skimdb to test bulk pull
replication in a real world situation.
 - Added the test pull-replication-one-generation that will generate 1000 first generation docs against a local CouchDB server and then pull replicate them.
 - Added the test pull-replication-two-generations that will generate 1000 second generation docs against a local CouchDB server and then pull replication them.

pull.request.test.object.js -
 This contains a class that creates a test harness for pull replication tests. It lets the caller decide how many generations they want, how many docs, what batch size, how
many sockets, how many iterations and also what latency they want. The ability to control latency lets one implement a very crude simulation of network delays. See common-utils
for details on how this works.

test/performance/utils.js -
 - Fixed the code so that if iterations == 0 then a test won't run at all.
 - Switched the default PouchDB instance to use the common Util safeRandomDBName function
 - Added a new feature to specify a tear down function for a test to do per test clean up

common-utils.js -
 - Moved couchHost from tests/integration/utils to here so we can re-use it in the perf tests
 - Added function safeRandomDBName to create unique names for DBs in tests
 - simulateNetworkLatencyInNode introduces a reverse proxy through which requests are sent to the final destination. The reverse proxy will slow down each request by a
specified latency. This is not a terribly accurate way to simulate network latency as it doesn't penalize, for example, for opening and closing lots of TCP/IP connections. But
it's a start.
 - simulateNetworkLatencyInBrowser - Simulates network latency by taking over XMLHTTPRequest and delaying each send request by a specified time. Again, as above, this is a very
primitive way to simulate latency.
 - isBrowser, self explanatory. Thanks to @calvinmetcalf for pointing out how to do this
 - createDocId, generally useful
The performance tests believe they are in node and will access 5984 directly, the test needs to change to detect if we are in a browser for it to pass on travis