Remove ManagedRepo.createOriginalFile

Dangling methods like this exacerbate the checking
of possible synchronization issues. The one method
which should be allowed is register(); any others
should be refactored away.
Replace create() test method with RawAccessRequest

The create method was the last remnant of the previous
multiplicity of ways to create files. These have now
all been consolidated into "register()". This poses a
problem for testing though. It's no longer possible to
modify the file system without also updating the database.

In order to simulate a background user (non-OMERO) modifying
files within the repository with OMERO's awareness, the
RawAccessRequest command can be used to touch or remove files.

This can only be done by an administrator.
Add UnregisteredFileException

file() and fileById() now throw an omero.UnregisteredFileException
if a file exists on the filesystem but is not registered in the DB

The `file` field of the exception returns the OriginalFile object
which would be created if register(String path, String mimetype)
were called on the same path. If the object on disk is a directory,
mimetype must be null or "Directory".
Set mtime on RawFileStore.save
TestDbSync: fileExists and mtime methods
Fix CheckedPath.asOriginalFile javadocs
Fix long-missing DELETE EventLogs

This check has been wrong throughout the 4.4 series.
If this is the last element, then EventLogs should be
raised for every OriginalFile deleted. This has not
been happening. (Very sadly)

This should be rebased onto dev_4_4
Fix typo in psql-footer.vm

This code path is only ever used if an event
is needed *outside* of OMERO, for example if
on the PSQL command-line one wants a synthetic
event id. In other words, not very frequently.

Regardless, this should also be ported to dev_4_4
Refactor deleteSingleFile to simplify flow
4.5DEV__3: _fs_deletelog table plus triggers for creation

The previous delete paradigm consisted of:

 * start transaction
 * delete all original files (etc)
 * pass the IDs for those files out
 * cleanup files under /OMERO/Files, based on id

Now that files are no longer stored based on their IDs
this doesn't suffice. The information from the OriginalFile
table has to persist beyond the transaction so that the FS
files can be cleaned up. The only TX-safe way of doing this
is to put them in another table, so that if the TX fails,
the copied instances are also removed.

A after-delete trigger now copies the relevant fields from
originalfile to _fs_deletelog. SqlAction instances can query
these logs to allow for proper cleanup. If deleting of the
files fails (as periodically happens on Windows, for example)
the logs will persist and a later administration console could
list the dangling files.
Fix deleteRepoDeleteLogs (SQL/tx)
Merge pull request #638 from joshmoore/fs-delete-1

_fs_deletelog via triggers