Wait for completion of an upload before segmenting more partitions

Explained a comment in the source:

	Wait for the pool to contain additional capacity before
	apply_async-ing even more uploads.

	Reasoning: 'parts' is lazy and generating each 'tpart' from it
	is memory and cpu intensive, so avoid doing it all at once
	when the parallelism is
Free TarInfo instances more aggressively
Apply tar member cardinality limit to segments

To avoid excessive memory usage in database clusters that have many,
many very tiny files that can be jammed into one partition.
Refactor partition constants into readable symbols

Now that there are two of them this seems more useful.  The magical
number for PARTITION_MAX_MEMBERS has been altered slightly in its
absolute value (it's smaller) and derivation (to make it round more
neatly with a Postgres page-aligned quantity, as to say more about how
many small-ish files would fit in one such partition).