The main goal here is to provide a foundation on which we can build,
and that allows to quickly convert all the existing configurations, so
that we can drop the old configuration quickly and don't have to
maintain two parallel configuration mechanisms over an extended period
of time.

The interfaces and implementations will likely change, particularly as
we evolve the configuration to add another layer on top of it.  As
such the primary goal here is to provide a sort of stable interface
for the actual users of the CP algorithms, so that they don't have to
constantly update as we tune/change this.  I'd also like to keep the
actual structure of the configuration blocks sort of stable, but I'd
expect some degree of changes here over time.

The main ingredients of this configuration model are:
* ConfigBlock: The actual object specific configuration classes
  that have individual implementations for each group of algorithms that
  should be configured as an indivisible unit.
* ConfigSequence: A sequence of blocks, though technically this could
  just be a simple python list instead.
* ConfigAccumulator: A helper object that is used to track all the
  information needed to communicate between (and within) blocks.
* container references: Helper objects that track all the shallow copies
  belonging to the same logical object.  This is taking the place of the
  current post-configuration step, essentially front-loading the
  connections between blocks.