Improve pixel data log handling

See:
 * https://www.openmicroscopy.org/community/viewtopic.php?f=4&t=7593&p=14636#p14636
 * http://trac.openmicroscopy.org.uk/ome/ticket/12526
 * ~~https://trac.openmicroscopy.org.uk/ome/ticket/12538~~ (not fixed)

A number of issues were reported by @PaulVanSchayck regarding delayed and skipped pixel data generation in the above thread. Until a proper message queue is in place (/cc @jballanc), these fixes should simplify how pixel data events are processed at the cost of no longer preventing one user from flooding the queue as well as prevent single-threaded operation.

## Testing ##
 * Disable the `PixelData-0` service
 * Upload a number of large images as user1 (Paul suggested 10. I'm using fakes for this purpose)
 * Upload one as user2
 * Upload one as user3
 * Re-enable the `PixelData-0` service.
 * Wait until the service is finished processing.
 * Viewing the related dataset (or "Orphaned") should show all the objects without the clock icon.
 * Before this PR, some of the pyramids would not be generated until a manual refresh was performed. 

Note: please take into account the web behavior outlined in https://trac.openmicroscopy.org.uk/ome/ticket/12538 when testing, namely that a clock icon may persist despite in-browser refreshes. Therefore it **may be simpler** to test this PR by checking for the existence of the `*_pyramid` files.

If you revert to the previous log loader with @PaulVanSchayck's fix (b518f1f) you should still see no images being skipped, though you will see only one thread working at a time. To do this, use:
 * `bin/omero config set omero.pixeldata.event_log_loader pixelDataPersistentEventLogLoader`