Add a new xcancel parameter to better control the flow of standard UI edit forms

When trying to create a flow for your an application, you can use the xredirect parameter to the URL of a standard create/edit UI page so that, when the user successfully creates an entry of you application, he gets redirected to the page you want him to.

However, the xredirect is also used by both the SaveAction and the CancelAction, so you can not really control what happens when the user tries to create a new entry but then cancels the create/edit form, i.e. to differentiate between the 2 cases: success and cancel.

For some cases, like XE-1466, this could be enough, but for others it is not.

As XWIKI-880 explains, it might make sense for use to start redirecting users back to the previous page if they try to create a wiki/page/entry/etc. but decide to cancel the creation form, instead of leaving them stranded on a non-existing page.

One way we could do this is to add a new request parameter, specifically for the CancelAction (e.g. xcancel) to specify where to redirect in case the user cancels the form. The CancelAction would:

1. look for an xcancel parameter
2. look for an xredirect parameter
3. ultimately falling back on the current document in view mode.

This would allow all 3 use cases that we currently see and/or need:

1. Redirect to X for save but Y for cancel (XWIKI-880)
2. Redirect to X for both save and cancel (XE-1466)
3. Redirect to the current document in view mode (standard behavior)

The edit forms would also need to be updated to read this value from the URL into a hidden input, like they do for xredirect.