Change MAX_BUFFERED_QUERIES to a byte measure and count buffer bytes

Per GitHub issue #194 and the comments above MAX_BUFFERED_QUERIES,
we're using a pretty rough heuristic for receive buffer management.

This approach can't account for the data in prepared queries that
return generated keys, it assumes a flat 250 bytes per query
response.

Change that, the buffer in bytes, up to an estimated MAX_BUFFERED_RECV_BYTES
(still 64k, same as before) with an estimated NODATA_QUERY_RESPONSE_SIZE_BYTES
or 250 bytes per query.

Behaviour is not changed, we're just counting bytes instead of queries. This
means that it's now possible to adjust the baseline
NODATA_QUERY_RESPONSE_SIZE_BYTES for the size of any returned columns in a
query with a RETURNING clause in a subsequent patch.
Document batch result set handling, other comment fixes
Factor deadlock avoidance code into subroutine
Support batching for prepared statements that return rows.

With this change, PgJDBC calculates the estimated return size for the result
row, assuming that each batch item returns one row for getGeneratedKeys() use.

Instead of forcing batching off and sending individual queries, it then queues
enough binds and executes to fit safely within the receive buffer and server's
send buffer before sending a sync and reading the result buffer.

Batching is still forced off when the result set size cannot be estimated (e.g.
due to unbounded 'text' columns, use of arrays in the result set, etc).

This is a minimal workaround for github issue #195, though it doesn't prevent
deadlocks that can already occur due to #194.
Merge pull request #204 from 2ndQuadrant/batch-returning-support

Add limited support for returning generated columns in batches

See individual commits for notes on the limitations. This isn't a perfect solution to issue #194 and #195, but it'll work well for most people.