Add failing test for #12145 rendering settings

Currently, it's not possible to share rendering settings
since the service methods all limit lookups based on the
current user.

This test shows the behavior we would like to see: if
user "other" does not explicitly generate rendering
settings, then none should be created.

There may be permissions issues with this that either
have to be handled in the clients or be worked around
by simplying copying the rendering settings from the
image owner (without re-**generating** them)
Modify all queries to try pixel.owner.id when empty

This may not be correct overall, but it at least lets the
previously failing test pass. Where a query was made against
`obj.details.owner.id = :user_id` we fall back to using
`obj.details.owner.id = some_other_obj.details.owner.id`.

Likely this code can be refactored into a single helper method.
Same type of quick fix for rendering

This new test failed before the PixelsImpl method was
modified. Now for all groups (not just `rwr--`) the rdef
for the owner will be returned if none is found for the
current user.
Add new API method: saveAsNewSettings

After @jburel's investigation, the remaining issue
with this branch looks to be that clients are assuming
(rightly) that the rendering def they have in hand is
their own. That's always been the case.

With this change, that no longer holds.

In order to not break the API the intention is:

 * the old method will throw an exception
   when users try to save someone else's rdef

 * the new method will *always* create a new
   rdef, set it as the current one, and return
   the new id.
Implement saveAsNewSettings with internalSave()

The primary logic from saveCurrentSettings which needs
to be avoided are the calls to `new.setId(old.getId())`.
`internalSave(boolean saveAs)` uses the saveAs argument
to skip over these sections.

The added test passes successfully.
Add check for ownership on saveCurrentSettings

To preserve the previous logic in which clients never
received RenderingDef instances belonging to other users,
we now detect when things have gone amiss and raise an
exception.

Client developers are responsible for checking the ownership
of the RenderingDef in hand and calling the appropriate method.
Generate thumbnails during saveAs

In order to not leave clients with NPEs,
when saveAs is called we also generate
the default 96 thumbnail.
Fix ThumbnailStore.thumbnailExists

thumbnailExists was broken and:
 1) throwing hibernate exceptions on save
 2) throwing NPEs during cache lookups

This should allow thumbnailExists to work
again. We may need a thumbnailExistsByLongestSide
method though.
Fix stackoverflow on loadAndPrepareMetadata

The old method signature was calling itself leading
to an infinite recursion. Slightly scary that this
wasn't more apparent.
Review save settings method.
Specify original object

This should be handled using the pojo objects (breaking change).
To be replaced on develop.
Generate thumbnail for user w/o thumbnail and w/ settings.
Check that settings owner equals session owner.
Create a new thumbnail if none associated to rnd settings.
Re-load rendering engine after save as.
Return a copy of the settings to viewer.
Reload settings.
Updated header.
Blitz re.saveDefaults() saveAs if rdef not owned. See PR2365
Modify saveCurrentSettings behavior to create rdefs (See #12145)

After an extended discussion this morning, we decided to change
the saveCurrentSettings method to internally call saveAsNew if
the rdef does not belong to the current user.

The previous behavior was causing 5.0.1 clients to fail (4 tests
this morning were red.) The only sacrifices that had to be made
were:

 * thumbnails couldn't be generated at the same time, and
 * *intentional* saving as another user is no longer supported.