Fix build-schema target

Previously it's been required to define omero.db.dialect
to be the Hibernate class rather than the one from
ome.tools.hibernate.*. By having two settings in
etc/profiles/psql, it's possible to return to the simple
build-schema call.
OMEROMetadataStore: removed unused fields and methods
OMERO4.5DEV__4: Add fs-image and fs-plate links

In order to have the fileset prevent inadvertent deletion
of only parts of a fileset, it's necessary to have hard
links between the fileset and generated objects. A more
optimal solution would allow linking to any top-level
object (similar to annotations), but for the moment this
should suffice.
Link images/plates and return during import

The OMEROMetadataStore is an internal API that's never
been directly exposed to users, therefore we change the
method calls to allow passing in the current fileset as
well as return the plates and the images which are not
in a plate.

At the moment, these are only displayed on the CLI.
Display fileset id on import

Primarily useful at the moment for having a fileset
ID for testing delete, the Fileset lookup should be
clearly defined in importImage(). As it currently
stands, getting hold of the fileset is probably too
complicated.
Simplest Fileset spec (for deletion)

This deletes all of the objects which are connected to a fileset
and requires that all of them be fully deleted to pass. This may
be a too strict interpretation of what should happen, and some
dangling objects (specified by a "SOFT" parameter) could be allowed.
Working FS delete for /Image specs

This has only been tested with single-file image formats
(and not plates) but should allow clients to begin trying
to delete via the /Image spec (which is how the currently
delete)

The recursive nature of the fileset graph makes this more
complicated that would have otherwise been necessary. If
adding /Plate support is equally difficult, it may be necessary
to change how the Spring initialization works in order to
even circular dependencies.
Working FS delete for /Plate specs

Similar issues are present as for the /Image(+FS)
spec. Also note that this leaves directories (along
with the OriginalFile objects) dangling.
Working FS delete for /OriginalFile specs

This currently does *too much*, in that asking to delete
any file in a fileset, will delete the entire fileset --
without warning! But at least it gives us the option of
providing an alternate spec like "/OriginalFile+FS".

Note: this will not yet take into account the actual file
structure, nor is that really tenable unless with link
OriginalFiles to OriginalFiles. Further, since directories
are not related to the Filesets, it will be possible to
delete them and thereby leave the rest of the fileset
"lost"!!
Merge pull request #663 from joshmoore/fs-image-links

Fs image links