Refactor and link modulo annotation creation

This is largely a cleanup of the three copies
of modulo creation for Z, T, and C. Notable is
the call to Image.linkAnnotation which was not
previously being called. Without this, OMERO is
not aware of the annotation.
Fill OME model objects

This is a suboptimal solution since it will require
other interface implementors to also implement the
new methods, but this was the simplest way to provide
the necessary XML parsing for individual elements.
Refactor methods into XMLTools and remove API changes
Disable OMERO Ann to test removal of NS

setValue() on the Modulo object was causing bfconvert
to fail due to XML parsing. This has now been disabled.
At the same time the NS elements from asXMLElement()
have been removed creating the desired block of XML:

```
    <XMLAnnotation ID="Annotation:90" Namespace="openmicroscopy.org/omero/dimension/modulo">
      <Value>
        <ModuloAlongT End="12304.687643793777" Start="0.0" Step="195.3125022824409" Type="lifetime" TypeDescription="TCSPC" Unit="ps"/>
      </Value>
    </XMLAnnotation>
```
Re-activate setValue but omit XML declration

XMLTools now permits disabling the `<? xml` block on
writeXML and dumpXML which allows us to move a step
further, though bfconvert is still failing with:

```
Exception in thread "main" java.lang.RuntimeException:
loci.common.services.ServiceException: java.lang.RuntimeException: Value node list size 2 != 1
```
Remove asXMLElement to prevent dupe Values
Wrap ModuloAlong element with Modulo
Also fix OriginalMetadata annotations in the same way

Note: the private 'value' field hides the proper xmlannotation
'value' field which is a bit confusing.
Fix unit test by clarifying getValue v. getValueForKey
Fix unused imports
Handle missing images

For /ome/data_repo/test_images_good/metamorph/jae/RGB_s34.tif
`getImage(imageIdx)` throws an IndexOutOfBounds exception since
there are no images detected. In this case, modulo handling is
exiting prematurely since there's no image to link to.
Make OM and M Annotation classes public

In order to be properly tested, these classes need
to be made public. This is also the beginning of the
definition of their public API which will also be
further defined via ticket 4536
Expect double rather than in for start/end/step

Following exception was thrown for start=0.0 when converting
an ome.tiff with modulo annotation back to ome.tiff:

```
Populating metadata
Exception in thread "main" java.lang.NumberFormatException: For input string: "0.0"
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
    at java.lang.Integer.parseInt(Integer.java:492)
    at java.lang.Integer.parseInt(Integer.java:527)
    at loci.formats.services.OMEXMLServiceImpl.getModuloAlong(OMEXMLServiceImpl.java:564)
    at loci.formats.services.OMEXMLServiceImpl.getModuloAlongT(OMEXMLServiceImpl.java:528)
    at loci.formats.in.OMETiffReader.initFile(OMETiffReader.java:834)
    at loci.formats.FormatReader.setId(FormatReader.java:1360)
    at loci.formats.ImageReader.setId(ImageReader.java:781)
    at loci.formats.tools.ImageConverter.testConvert(ImageConverter.java:337)
    at loci.formats.tools.ImageConverter.main(ImageConverter.java:672)
```
Skip modulo generation if one already exists

Previously, when trying:
```
./bfconvert -no-upgrade -overwrite FLIM-modulo-sample.ome.tiff /tmp/flim.ome.tiff
```

Two modulo annotation blocks appear in the output TIFF comment.
With this commit, later calls to addModulo() are silently ignored.
Temporary fix for rotation (See #11720)
Merge pull request #820 from joshmoore/7856-flim-ann

7856 flim ann