Post data save imgRdef

[will-moore]

This is part of a fix for ome/omero-iviewer#545

To avoid issues with long URL request parameters when saving rendering settings, we use the POST data (instead of the URL).
The saveImgRdef endpoint will now accept both forms.
The Preview "webgateway" viewer uses the POST data to handle the params. This doesn't need any change in construction of the query string or the parsing of the parameters in Django.

To test:

• Import an image with lots of channels (either a fake file or the sample from user above - Zenodo link at Scalability limits of OMERO (large datasets ~500TB) and channel handling limitations for high-dimensional images (100+ channels) omero-iviewer#542 (comment))
• Try to save new rendering settings (or a server with e.g. 4k request limit - not local dev server!)
• Test saving without using data for POST params - e.g. by using iviewer (without Use POST data for saveImgRdef params omero-iviewer#546), to check that endpoint works with both forms

[sbesson]

Wasn't the ability to use POST requests for saving rendering settings already introduced in #606?

[will-moore]

@sbesson Ah, hmmm - #606 solves the long query string problem for rendering images by removing inactive channels. But it doesn't change the URL length for saving rendering settings.

We can update the viewport.getQuery(true) in this PR to viewport.getQuery(true, undefined, undefined, false) to NOT include inactive channels in the query when Saving. However, that has a slight change in behaviour.
Currently, if you go through a bunch of channels making rendering settings changes (e.g. colour, min/max etc) but then you only have 1 channel active when you Save, you will only save changes to 1 channel.

However, this PR would allow you to save inactive channels.

[sbesson]

@sbesson Ah, hmmm - #606 solves the long query string problem for rendering images by removing inactive channels. But it doesn't change the URL length for saving rendering settings.

#606 reduced the length on the query string for rendering requests but it also enabled some POST requests. Reading more carefully at the changes, the scope was limited the /webgateway/copyImgRDef endpoint and fixing the copy of rendering settings when working with images including a large number of channels.

[will-moore]

@sbesson Agreed. But no changes on #606 were made to the saving behaviour / or url length.

To enable saving of rendering settings for images with many channels, either we:

• Only save changes to active channels (remove the active channels from rendering query as in Fix issues related to images with very high channel count #606)
• Or we put the rendering info in the POST data body of the request instead of the rendering string (as in this PR)

The 2nd option gives a nicer experience for users because it will save any changes they've made to inactive channels (which is the current behaviour).