first attempt at a block configuration, add block configuration for muons

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.

I'm marking this as Draft to give people a chance to comment, but I'd like to get this in soon. As I said, the main thing here is that we can still do everything we can do with current configuration (and that we actually do) and to make sure that the way it is used can be kept stable for a reasonable amount of time. There is probably some amount of polishing that could be done to the blocks, but I wouldn't want to take that too far as we haven't worked out the configuration layer they ought to fit into, so polishing it too much may just be wasted effort.

Maybe some points for people to comment on:

• I still have functions for creating the individual blocks, modeled on what we have right now. Do we need that or should people just directly create the blocks? The main advantage I see of these functions is that we can do a lot more tinkering with the blocks without disturbing the users.
• We probably will at some point will have some sort of user configurable properties on the blocks that we can then link up to the configuration file. We could of course define them now, and probably at least the basic framework would stay the same as we adapt them to a higher configuration layer, but I'm still inclined to leave that for a later point, unless we already need it now.
• We could/should probably define some helper function that does all the steps to convert the block sequence into an algorithm sequence, instead of having to call the functions manually.
• Currently the selection sequences as a last step load an algorithm to combine the selection decorations into a single decoration flag. I just dropped that. We should probably just autogenerate those algorithms based on the declared selection names, but that isn't done yet.
• I converted each current sequence into a block, and that's the plan for the remaining sequences. If people actually manipulate the algorithms in the sequence after creating it (e.g. remove/reorder algorithms), that would likely mean we need more fine-grained blocks.
• The way I handle selection meta-information is mostly a very simplistic translation of how the current selection meta-information is handled.
• The shallow copies are handled through object references/copies; mostly that's code straightly lifted from my text configuration prototype. That's the one part of that prototype I actually like, it simplifies both the actual code managing the shallow copies and how the shallow copies are accessed in the algorithm configuration as well.
• Just like the current configuration this is a multi-step configuration, but the order is inverted, with the actual algorithm sequence only being created in the last step, once all the meta-information is known to do a complete configuration of the algorithms. That avoids the configuration code having to go in and change algorithms that have already been added to the sequence, which is where a lot of the messiness of the current configuration comes from.

There are probably other obvious points I forgot. If I remember I'll add them here.

Tagging the usual suspects: @tadej @jburr @strichte @lheinric @vimartin