Some intial performance work

[brianc]

I did some experiments with sending flush more regularly & I saw query throughput on a very, very basic benchmark improve by about 10%. I'm wondering if this has more impact or less impact on situations with more latency as my benchmark was running locally. I'm particularly trying to shake out what's impacting things in #1993 and #1952

I also removed some sort of micro-optimization I made a long time ago that isn't helping anymore. I saw small speed increases, but I think it might help the ClienRead delays in certain cases. I was buffering up a bunch of messages in the process (parse, bind, execute) before sending any of them. Now I'm just writing them all to the wire when the come in, and following each w/ a sync to help the backend send it's responses as quickly as possible as well.

[STRML]

Hey @brianc, we're doing some checking up on how node-pg sends anonymous prepared statements and perf compared to libpq in binary_parameters mode. From my read of the code, node-pg actually handles this well because it doesn't do parse --- wait --- bind/describe/execute/flush, it just sends them all in one go, as libpq does in this mode. Please correct me if I am mis-reading. The main point of interest is compatibility with transaction pooling adapters such as pgbouncer which won't be able to keep state across multiple round-trips.

That said, this PR and #1993 are of interest. Where did this investigation end up after you closed this PR? I see https://github.com/brianc/node-postgres/tree/bmc/make-faster 404s now as well.