This PR separates the plotting logic of PixelMap from the class itself. The way this was worked out might feel a bit clunky, but is scalable for other objects.

datahandling/pixelmap.py defines the classes that contain pixel map data.
plotting/pixelmap.py defines a PixelMapPlotting class, which contains all methods related to plotting.
plotting/pixelmap.py defines the configurations for the pixel maps, e.g. TIVMapPlotConfig.
plotting/__init__.py contains a registry of configurations.

PixelMapPlotting contains all plotting related logics. You could access them with e.g. PixelMapPlotting(pixel_map).imshow(...). However, pixel_map.plotting.imshow(...) does the same thing, and should be used instead in most cases.

The configuration for plotting is stored in pixel_map._plot_config, but should be accessed through pixel_map.plotting.config.

The config registry contains the default configurations for each PixelMap subclass, e.g. TIVMapPlotConfig. The advantage of this registry is that it can be updated during runtime, which means someone can change the default values at the start of their script. When a TIVMap is initialized, it copies the associated values from the registry. Updating the config for an individual TIVMap instance does not overwrite the defaults. Overwriting defaults does not influence existing objects.

This approach is highly scalable. We can use the same code for e.g. ContinuousData and its plotting config. A default ContinuousDataPlotConfig could use the unit attribute of ContinuousData to create an axis label. If someone has e.g. a lot of pressure data, they could create a subclass of ContinuousData called PressureData, create a PressureDataPlotConfig, register it, and use it throughout the code.

NB: this PR is aimed at feature/mask_class, since it depends on the Mask class.