Scan base cleanup

This MR cleans the scan base. Addresses #334 (closed) #336 (closed) #347.

Changes in addition to the issues:

• Remove too complex per module scan feature
• Create folders and files only at init step
• Modules are given a serial number identifier. This does not have to be defined.
• Create folders according to module_name/chip_name. Different serial number does not have to be defined, to ease quick testing of modules.
• Modules define in testbench if power cycling is wanted. This is not a parameter of a scan any more.
• Chips define in testbench if record chip status is wanted. This is not a parameter of a scan any more.
• Rename scan_config_override_per_scan --> scan_config_per_chip
• Leaving chip_configuration empty means that chip config of latest scan is loaded. auto is not needed any more. Renaming to chip_config_file, since the chip configuration is more than the file.
• No chip_conf_directory in testbench any more. The chip path defines it already and one can change the config files already.
• Rename bdaq config key in scan_configuration to bench, since it updates the bench config
• Chips define in testbench.yaml to use_good_pixels_diff
• Std. config yamls define chip type for cross check
• Configuration node in h5 file has all configuration parameters, separated into 3 nodes: chip, scan, bench
• scan.scan will be re-renamed to old method name start
• A scan creates a configuration before config (configuration_in) and a final configuration after analysis (configuration_out)
• H5 files are not creating memory leak anymore
• FIFO reset happens after all chip configure and not during first chip readout start in scan function

Regressions:

• No check if send_address for all chips are different
• Power cycle of modules likely not working power cycling works
• Maskfile concept removed
• No exception handling per chip. If one chip of a module creates an exception everything is stopped.

Open questions:

• What about the TRIM concept --> just copied over
• Why to preselect what pixel registers to store and not just dump all? --> filter removed
• There are calibrations in the chip and in the test bench yaml. How to they interplay? --> testbench calibration just dumped as non parse able string for now. Chip calibrations available and parsed.
• Reset register after scan feature required? Otherwise a changed VCAL_HIGH setting is taken from previous scan --> should be ok, since all scans that use injection are in charge to set the registers as needed and should not rely on std. cfgs.
• Shall we keep the special treatment of chip registers in the scan_configuration or shall we require a chip key for chip related scan settings? --> it is not the case that scan_configuration sets chip registers directly
• renaming disable_pixel to use_pixel, since the logic is inverted? --> Yes

Status:

• __ init __
• init
• configure
• scan
• analyze
• close
• start
• load config from h5
• unit tests for scans
• implement chip cfg loading from previous run
• unit tests for analysis
• check scan parameter storing
• create new fixtures
• version increase
• test with real chip
  • test loading chip config (register, masks) from previous runs
  • test that tuning results after running a scan (e.g. Vthin_x) are written to configuration_out
  • test that the configuration is properly used for many chip scans
  • multi-module / chip feature
  • check that periphery does what is should