WHY IS THIS CHANGE NEEDED?:
- when using single_birth_plot routine, user can change the label in
  the legend that indicates birth events

HOW DOES THE CHANGE SOLVE THE PROBLEM?:
- remove hard-coding of the 'birth event' label by making it an argument
  with the default of 'birth event'.
- this preserves backwards compatibility as i'm creating a new argument
  and the existing argument names are the same

WHAT SIDE EFFECTS DOES THIS CHANGE HAVE?:
- backwards compatibility: existing uses of this routine in scripts will
  produce 'budding event' in plots rather than 'birth event'; if a user
  wants to use 'birth event', they can simply define the argument
  birth_label='birth event'.

EVIDENCE THAT COMMIT WORKS:
- works with a random time series and a binary mask-like numpy array,
  and i can change the legend label

REFERENCES:
- issue #36

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.

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 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.