Use ome-common 5.3.1

[rleigh-codelibre]

Needed for testing ome/ome-common-java#8 and ome/bioformats#2648

[sbesson]

This set of PRs forces us to reevaluate our development workflow following the OME component re-architecture done in 5.3.0-m1. I see two separate issues that need to be handled when dealing with coupled PRs across Maven repositories:

1. dealing with SNAPSHOTs of transitive dependencies in particular for low-level components like ome-common. One approach proposed here is to bump all the intermediate components to propagate the SNAPSHOT to the high-level component. An alternative approach mentioned in Add JPEG-XR support for CZI data bioformats#2648 (comment) would be to explicitly add a dependency to the low-level component at the top of the dependency section of the POMs and override the version without needing to bump the individual components.
2. dealing with the Travis validation. We have encountered the same situations during the 2016-06 OME Data model work as the OMERO branch was consuming Bio-Formats SNAPSHOTs under development. For large portions of the model development, the Travis status was effectively ignored until milestone versions were tagged, deployed and consumed.
   The major difference with the case described above is that it was happening on an integration branch and a green Travis was required for the reintegration into the main development line (Merge regions into develop openmicroscopy#4638). Here the concern with a failing Travis check is that it effectively means putting the master branch in a broken state.

In general, once coupled PRs have been tested together, there are 2 ways to resolve validation issues:

1. either merge the low-level PRs and push the SNAPSHOTS to a central place so that they can be consumed e.g. using https://oss.sonatype.org/content/repositories/snapshots/org/openmicroscopy/ as we have done in Remove ome-poi component bioformats#2624
2. or alternatively, have quicker releases for these low-level component i.e. bump the patch number, release a new version to Maven Central and update the components to consume this version in order
   The choice between these two solutions i.e. "long-lived" SNAPSHOTs vs releases might also depend on the context, the nature of the feature/addition and its potential impact.

In both cases, it would be good to discuss these workflows and our policy as part of a team.