Heatmap added x-ticks based on the time points, not absolute time.

When a DataFrame is passed into matplotlib.imshow, the Axes no longer
cares about the column names.  We want the plot to take into account the
sampling period AND the unit scaling if the user specifies one.

I copied over the method I implemented for boxplot.py -- it essentially
'tricks' matplotlib by redefining the labels rather than change the
time-axis values (see
https://stackoverflow.com/questions/10171618/changing-plot-scale-by-a-factor-in-matplotlib).
matplotlib's xscale does not support simple linear re-scaling; in any
case, having time-axis values does not make sense for imshow.

This commit addresses issue #20.

When the user defines xtick_step and sampling_period so that
sampling_period is not divisible by xtick_step, an error is shown.
Specifically:

    int(np.where(time_axis == label)[0].item()) for label in xticklabels
ValueError: can only convert an array of size 1 to a Python scalar

The routine assumed that all instances of label (line 66) can be found
in time_axis (defined in line 61).  This is not true when
sampling_period is not divisible by xtick_step -- as an example:

Suppose time_axis is: [0, 1, 2, 3, 4, 5, 6, 7]
And xtick_step is 0.6.
xtick_min is thus defined as 0 and xtick_max is thus defined as 7.2, as
expected.
xticklabels is then defined as [0, 0.6, 1.2, 1.8, ... 7.2]
In the list comprehension that defines self.xticks, label first acquires
the value of 0.  This results in no errors as time_axis contains a 0.
However, when label then acquires the value of 0.6, the ValueError is
returned because time_axis does not contain a 0.6.

Fortunately, Axes.xaxis.set_major_locator() does all this for me, so I
scrapped the original method of defining horizontal axis for this.  I
had originally written the lines to define the horizontal axis when I
didn't know that set_major_locator() existed, and tried to define the
x-ticks manually.

These changes should not affect the behaviour of heatmap apart from
cases that cause the error.

This commit fixes issue #19.

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.