Improve the units API

[ctrueden]

Specifically, this branch makes the Quantity superclass nicer to work with, and adds some helpful constructors with default unit specifications, to avoid errors when converting downstream code to the new API.

See here for an example where these changes would be helpful.

/cc @qidane
--no-rebase

[ctrueden]

I don't love the Unit<? extends Quantity> unit() declaration, but it's the best you can do without introducing a generic parameter to Quantity.

[ctrueden]

As an aside, it is a shame that the OME codebase could not adopt a standard units library. We will need to create an integration layer to bridge OME units to and from SciJava units. See scifio/scifio-ome-xml#23

[ctrueden]

OK, I see that there are a bunch of new FormatTools method signatures that return new quantities with default units. And I guess, if the default unit differs in the schema depending on which field it is, then the new constructors I added above make less sense and are in fact dangerous. Interested to hear others' thoughts.

[melissalinkert]

I'd prefer to see 17300c4 reverted, but the other changes read fine.

[ctrueden]

@melissalinkert Are there ever two fields in OME-XML that use the same quantity but different units? If so, I will purge the commit. But if not, what's the harm?

If we do eliminate that commit, I would still like to see shorter API calls to create new quantities. As things stand, it is a little verbose to write meta.setPhysicalSizeX(FormatTools.getPhysicalSizeX(pSizeX).

[melissalinkert]

PhysicalSizeX on Pixels, PositionX on Plane, and EmissionWavelength on Channel all use the Length type, but with different default units (microns, reference frame, and nanometers, respectively).

[ctrueden]

Thanks @melissalinkert, I purged 17300c4 from the branch.

[melissalinkert]

Thanks. All reads OK now, just waiting on inclusion in the merge builds.