Use a consistent row convention throughout

Steve's code originally used a "top-down" counting of the row numbers,
while the code in the STAR framework (database, hit maker) uses a
"bottom-up" definition. However Steve's code seems (largely) insensitive
to the convention being used, as it is only interested in tower
separations. Therefore remove the different conventions. This simplifies
things, as we previously converted from bottom-up to top-down before
runnings Steve's code, then back again afterwards. Now we just skip
these two conversion steps.

Note there are some small numerical differences that come from this.
They seem to be due to
- an effect due to the y offset used, as it is not quite nrows / 2 * row
  height e.g. for large detectors, the offset in the database is 98.8,
  but 17 * 5.812 = 98.804
- I noticed that some clusters/photons come out of the fitting with
  (x, y) = (0, 0). These distort the QA plots when included and should
  be filtered out in future

Closes #4
Omit clusters reconstructed at x, y = 0, 0

The (0, 0) coordinates of these clusters is invariant under the change
in row counting convention (top-down to bottom-up). This leads me to
believe that they are bad clusters, or are at least not suitable for
analysis. The (0, 0) coordinates seems to derive from the cluster
moment calculation, but I don't understand enough of what is going on
there to know exactly what the problem is.