fix: debug post-merge requests 10, 11

See merge request aliby!12

WHY IS THIS CHANGE NEEDED?:
- a case in which x and y dimensions are unequal is better at revealing
  dimension storage/conversion issues

HOW DOES THE CHANGE SOLVE THE PROBLEM?:
- tile existing image to size x = 1800, y = 1200

WHAT SIDE EFFECTS DOES THIS CHANGE HAVE?:
- filenames have changed

EVIDENCE THAT COMMIT WORKS:
- doesn't seem to break existing tests, specifically test_image.py and test_tiler.py

WHY IS THIS CHANGE NEEDED?:
- TypeError raised when Tiler.dummy object was instantiated ('method'
  object is not iterable)

HOW DOES THE CHANGE SOLVE THE PROBLEM?:
- dummy_omero_metadata was a tuple of dicts, changed it to a dict.  this
  also makes available the .update() method of a dict.  and is also
  consistent with the datatype it should be in the return statement.

EVIDENCE THAT COMMIT WORKS:
- Tiler.dummy object can be instantiated from a parametes dict without
  errors

- Change the order to match tczyx where appropriate
- Make name and dimorder properties for Imagedummy

REFERENCES:
- issue #62

WHY IS THIS CHANGE NEEDED?:
- using dev_testimage.py in skeletons: when dummy tiler is created and
  tiler.initialise_traps() is invoked, segment_traps() (still) raises 'No valid
  'tiling regions found'

HOW DOES THE CHANGE SOLVE THE PROBLEM?:
- in tiler.initialise_traps(), initial_image was defined based on
  self.ref_channel and self.ref_z; however, if ref_z was not 0, then
  initial_image would be a zero array.
- this was because ImageDummy.pad_array() put the input image at the 0
  position and pads with zeros regardless of the value of ref_z.
- so i wanted the output of ImageDummy.get_data_lazy() to be defined in
  such a way that the (ref_z)th slice in the z-direction is the input
  image.
- therefore, i added a new argument to Image.Dummy.pad_array() so
  that ref_z can be used to achieve the above.

WHAT SIDE EFFECTS DOES THIS CHANGE HAVE?:
- tech debt: no (easy) way to deal with ref_channel because it's a
  string.  workaround is to keep the ref_channel the first channel
  in the dummy tiler, and assume that throughout.

EVIDENCE THAT COMMIT WORKS:
- modified test_image.py works
- skeletons: dummy tiler can be defined and dummy_tiler._run_tp(0) runs
  without errors

WHY IS THIS CHANGE NEEDED?:
- when tiler.initialise_traps() is invoked, "No valid tiling regions
  found" is raised from traps.segment_traps() (aliby.tile.traps).

HOW DOES THE CHANGE SOLVE THE PROBLEM?:
- the image called by segment_traps() was a blank image.
- this was because tiler.initialise_traps() uses the first timepoint to
  define the initial image (line 400 in tiler.py).
- the first timepoint was a blank image because ImageDummy.pad_array()
  added zero arrays BEFORE the input array.
- so fixed it by reversing the behaviour of ImageDummy.pad_array()
- and modified the test_image test to reflect this change.

WHAT SIDE EFFECTS DOES THIS CHANGE HAVE?:
- none known -- only potential effect is the test, which was modified

EVIDENCE THAT COMMIT WORKS:
- test_image passed

WHY IS THIS CHANGE NEEDED?:
- tiler dimensions are ctzyx, but image dimensions are tczyx by default.
  this leads to incorrect storage of shapes

HOW DOES THE CHANGE SOLVE THE PROBLEM?:
- re-arrange the dimensions in the shape property to match image
- justifying this for the purpose of getting ImageDummy to play well
  with Tiler

WHAT SIDE EFFECTS DOES THIS CHANGE HAVE?:
- this exposes technical debt: there are places in which the order of
  dimensions are hard-coded and later assumed like this, and leads to
  indexing dimensions by index rather than by name.  in addition, the
  assumed order of dimensions is inconsistent throughout tiler.  this is
  a recipe for confusion.  worth a refactor soon.

WHY IS THIS CHANGE NEEDED?:
- when new slices are added using ImageDummy.pad_array(), the original
  array is at the end

HOW DOES THE CHANGE SOLVE THE PROBLEM?:
- for consistency, made the 'nil' elements precede the reference channel

WHY IS THIS CHANGE NEEDED?:
- it complained that ImageDummy object has no .shape attribute when
  Tiler methods like ._run_tp() were called

HOW DOES THE CHANGE SOLVE THE PROBLEM?:
- first argument of the object to be returned by .dummy() is mistakenly
  an Image instance (i.e. ImageDummy); it should be a dask array like
  those returned by e.g. .from_image(), .from_h5()
- fixed by using the .data attribute, consistent with the other methods mentioned

WHAT SIDE EFFECTS DOES THIS CHANGE HAVE?:
- order of dimensions is inconsistent: it is tczxy in io.image.py but
  ctzxy in the .shape() method in tiler.py.  this may break things down
  the line

WHY IS THIS CHANGE NEEDED?:
- consistency

HOW DOES THE CHANGE SOLVE THE PROBLEM?:
- fill in unspecified channels with 'nil' -- normally this information
  is fetched from metadata, which we don't have for this dummy

WHY IS THIS CHANGE NEEDED?:
- currently has one time point, one channel, one z-stack and thus
  mimicking usual Image.data structure.  this isn't what we want to test.

HOW DOES THE CHANGE SOLVE THE PROBLEM?:
- use pad_array() to pad with zeros so that the shape is as desired

REFERENCES:
- MR !10