Refactored how pieces and extents are handled.

Refactoring the way VTK goes between piece and structured
extents. Before, extent translators were used when the pipeline
moved from structured to unstructured data converting piece
request to extent request. This caused many problems with filters
that altered extents, mainly a lot of redundant IO due to
repartitioning of different extents. This became extremely
cumbersome to manage when running distributed. The new behavior
pushes the extent translation all to way to the readers and
only when readers are able to read a subset. This works much
better. The only downside is that filters need to be able to
handle data extents different than update extents. Most filters
can do this but many imaging filters cannot. Those that are
needed in parallel will have to be updated.

As part of this work, I also removed MAXIMUM_NUMBER_OF_PIECES
and added CAN_HANDLE_PIECE_REQUEST. MAXIMUM_NUMBER_OF_PIECES had
reduced to being a boolean. 1 for serial sources, -1 for parallel
sources. I removed it and added a CAN_HANDLE_PIECE_REQUEST instead.
This key, produced by a source, tells the executive that a source is
able to handle piece request. It is a source only key produced in
RequestInformation and is not propagated downstream. If this key is
not present, the executive will only execute the source for piece 0
to produce the entire data. It is then up to the user to add a filter
that splits the data for other piece requests. The only exception to
this is when CAN_PRODUCE_SUB_EXTENT is present, in which case the
executive will split using an extent translator AT THE source - not
downstream.

Conflicts:
	Filters/FlowPaths/vtkParticleTracerBase.cxx

Change-Id: I8db4040289ff87331adeecded4a738313d9b52df