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.