Change memory allocation in buffered block manager and sorter

The sorter and block manager currently allocate all of their memory
up-front. This patch changes that so that memory is allocated as a run
is built. Only the minimum number of blocks required are allocated
up-front.
Added a non-blocking TryExpand() call to the buffered block manager to
allocate a new buffer and assign it to a block. The only place where this
is invoked is when the sorter tries to extend a run.
While there are other ways of doing this, this seemed like a minimally
invasive change to make at this point.
In the merge phase, the sorter does not try to allocate more buffers,
but instead works with the buffers allocated up to that point. This is
something that is pretty easy to change.
Other changes include:
a) There is no longer a max_available_buffers() in the block manager.
   Replaced by a combination of available_allocated_buffers() and
   TryExpand().
b) In WriteUnpinnedBlocks(), unallocated memory is taken into account
   to determine if blocks should be written out.
c) The sorter uses a block to copy out sorted var-len data when
   unpinning the blocks in a run. This block is now allocated up-front.

Change-Id: Ifbb2ffd679a882afe8895f4785ec6d7c49c30b98
Reviewed-on: http://gerrit.ent.cloudera.com:8080/3148
Reviewed-by: Srinath Shankar <sshankar@cloudera.com>
Tested-by: jenkins