WHY IS THIS CHANGE NEEDED?:
- bug discovered via strain report script (skeletons, arin)
- TypeError raised if DataFrame from grouper output passed as input
  argument for mean or median plots
- doesn't affect other plotting routines and doesn't happen with
  manually generated random DataFrame

HOW DOES THE CHANGE SOLVE THE PROBLEM?:
- for some reason self.trace_time was defined as a numpy array with
  dtype=object, so forced it to be dtype=float.  as the dtypes are
  consistent now, coercion of inputs should be possible

WHAT SIDE EFFECTS DOES THIS CHANGE HAVE?:
- tech debt: other routines did not include converting to numpy arrays
  -- probably a simpler solution that works fine

EVIDENCE THAT COMMIT WORKS:
- run strain report script with amended routines and error now
  disappears

REFERENCES:
- issue #27

Specifying a sampling period via the sampling_period argument duplicated
multiplying the horizontal axes by a scaling factor.

This is because recent changes to postprocessor (see last paragraph of
commit) makes the columns of DataFrames show absolute time units (e.g. [0, 5,
10, 15...] if the images were taken every 5 minutes).  Previously,
columns showed time points (e.g. [0, 1, 2, 3...]).  All routines relied
on column labels to define the horizontal axis.  This issue would
have been addressed more timely if the commit in question had a more
informative description; 'add tiniterval property' tells me nothing and
does not inform me that it affects the column labels.

These recent changes mean that the sampling_period argument is no longer
necessary.  However, instead of deleting this argument, I've decided to
repurpose it for unit scaling, e.g. from minutes to hours.
Operationally, nothing has changed, but the meaning of the argument has
changed, and I've updated the docstrings accordingly.

This commit may affect horizontal axes of plots affected; users should
inspect the axes carefully, especially if the source data relies on
postprocessor.grouper.

This bug was likely caused by 17e13b59
on 2022-06-16 14:21.  It is unclear from the commit message, but I
suspect that this commit attempted to incorporate the image sampling
interval into defining the DataFrame columns produced by postprocessor.
This commit addresses issue #20.

Previously assumed normalised fluorescence readings.  Now that I am
using this for raw data and power spectra, this is no longer
appropriate.

This change will likely propagate through the other plotting routines...

When the plotting routines in postprocessor.routines are imported in a
different script or module, it raises an error that indicates that
`plottingabc` or `single_plot` are not found.

This is because I attempted to use relative imports without accounting
for how Python usually imports things, especially in a project with
multiple directories and multiple layers.  Relative imports can be done
via:

    from .foo import bar

But I opted against that in favour of absolute imports (the solution
implemented) because it conforms to PEP8.

This should not affect anywhere else in the code base as these are the
only bits where `plottingabc` and `single_plot` are used.

Users must now scale the input before passing it through the plotter.
In other words:
   PREVIOUSLY
      ax = mean_plot(trace_df, *args, scale=True)
   NOW
      from postprocessor.core.processes.standardscaler import standardscaler
      trace_scale = standardscaler.as_function(trace_df)
      ax = mean_plot(trace_scale, *args)

This creates slightly more burden on the user, but (hopefully) less
burden on the developer, for the following reasons:
- This avoids a 'multi-function function'.  In other words, the mean
  plotter used to scale the dataframe, THEN create a plot.  This should
  be two functions, and because core processes have `.as_function()`
  methods, scaling should be easy for the user.
- The mean plotter thus is more consistent with the other
  two-dimensional plotting routines, i.e. `single_plot` and
  `single_birth_plot`.  Refactoring to reduce code repetition should
  then be easier.

I didn't do the same thing for `heatmap` because scaling is intertwined
with setting the colormap scale.  That is, if `scale` is True, then the
axes must be even.  The handler *must* know whether the data has been
scaled in order to do so, so that is why I left scaling in `heatmap`.

This change is not backwards-compatible and users must check that their
data is scaled before invoking the mean plotter.

Users can import plotting routines and use them on DataFrames for data
visualisation purposes, e.g.:

    from postprocessor.routines.<type> import <type>
    <type>(df, **args)

or:

    import postprocessor.routines as ppr
    ppr.<type>.<type>(df, **args)

I essentially copied over
https://git.ecdf.ed.ac.uk/swain-lab/aliby/skeletons/-/blob/arin/scripts/users/arin/alibyplot.py,
but divided each plotting type into its own file to make it more
organised.

Currently, it's fully functional for any users to use, but there are
issues:
- General issues:
    - Code repetition, e.g.
        - Defining attributes in __init__
        - Defining Axes
    - Need to call ppr.<type>.<type> -- would be more convenient if
      ppr.<type> as if the user is using matplotlib.pyplot or seaborn.
    - Defaults, e.g. plot titles, are very specific to what Arin does.
- Specific issues:
    - By default, the heatmap creates Axes with the left half filled
      with whitespace.  This doesn't affect visualisation, but it's a
      minor annoyance.

I plan to eliminate code repetition by applying OOP/design patterns
later.

Addresses issue #14.