ome-xml: java: Don't report unhandled links prematurely

[rleigh-codelibre]

This PR is a second version of #81 but is Java-only and omits the C++ changes which are no longer applicable. Please also see the discussion on that PR.

This PR corrects some long-standing issues in the Java reference processing implementation.

• OMEModelObject::link implementations always chained up to their parent before handling the linking themselves. This works, but would result in the parent issuing a warning if it couldn't handle it, despite the child later handling the link. We now chain up only if the child can't handle the link, and issue a warning right at the top if nothing handled it. This solves a number of annoying Java model serialisation warnings which are completely bogus.

In effect, you will see that setting an AnnotationRef on Detector or any other element derived from ManufacturerSpec will no longer have ManufacturerSpec::link issue a bogus warning. This applies to any model object which is derived from another model object, e.g. LightSource, where the reference is handled by the most derived type, or any derived type after the first, where the chaining up will trigger the spurious warning.

For OMERO import, this should remove a large number of the bogus import warnings related to OME-XML metadata which we have seen on e.g. the QA system and other channels over the last few years. LightSource and Shape are notable culprits.

Testing:

• Run tiffinfo or tiffcomment on test.ome.tiff. Check that you get three AnnotationRef elements linking to the three annotations, demonstrating that the reference processing and subsequent serialisation worked correctly.
• Check Java with a similar sample for C++ metadata-formatwriter, creating an AnnotationRef on Detector or similar. You'll see the warnings go when built against this ome-model snapshot, but otherwise no other functional changes.

[rleigh-codelibre]

Rebased to run with GitHub Actions.