Introduce DetectorAssemblies

This MR aims at solving the conundrum that the assembly of a detector (hybrid, monolithic, ...) up till now is tied to the geometry chosen for the sensor (pixels, radial strips, ...).

The main change is a new parameter for the detector model files, called "geometry". Now,

• type will only be used to determine the assembly type and add additional chip and bump bonding layer if required
• geometry will allow to select the sensor/pixel geometry, also e.g. hexagonal grids in the future.

With this, e.g. a hybrid hexagonal detector can be used as well as a monolithic one. The only breaking change is that @rprivara's examples have to change from

type = "radial_strip"

to

type = "monolithic"
geometry = "radial_strip"

which should be okay since this is unreleased code, so no need for additional precaution. By setting a default geometry = "pixel" we are also fully backwards compatible with v2.x model files which only support rectangular pixels anyway.

Internally, there is now a new class (and sub-classes) called DetectorAssembly which hold information about the chip and bump bonding et cetera. Since the calculation of relative positions is quite involved and requires information e.g. about the sensor, many of the methods like getChipCenter() are still present in the DetectorModel class and internally combine information from sensor and assembly.

Some additional tests make sure that all components are still placed at the correct positions.

One thing to solve is the calculation of additional lateral extent from the bump bonding grid. Right now that's quite hacky and I'd like to clean that up.

I'd like to get some feedback on whether you deem this approach sensible and/or if you have ideas on how to improve or to do it differently. @hwennlof @pschutze @rprivara