Improve return location

Issue description

The current return location mechanism has some issues, mainly because it is browser wide and sometimes brings the user to an unexpected page which is his or her mental context is surprising.

Developer comments

[5686, Issue 5686] is resolved. This is confusing since it states that localstorage would be in use, but this is not true, sessionstorage is used and thus it is browser wide.

sessionstorage is per window and disappears when the window is closed. localstorage is browser wide and is not emptied when the browser is closed.

=== The problem === Given a browser B with windows W1 and W2 both using the same Topincs store. The current problem is that if W1 sets a return location L1 even a form in W2 will pick it up once a form is saved basically snatching it from W1. This is confusing in several ways for the user: 1) surprising form continuation in W2 returning to location L1 despite being in a completely different context. 2) the lack of returning to L1 is also surprising. === The solution === The return location may only be in storage during navigation. The following rules should apply: * In W1 return location L1 is set. * L1 ishould be moved from storage to JavaScript on page load in W1. So identifying windows is key. * W1 edits a form then L1 is used and deleted. * L1 may be deleted from W1 in under circumstances, e.g. it is replaced or simply deleted because the window is used for something else.

The problem as described above could not be reproduced. The currently implemented return location mechanism is window/tab specific and is not transferred between windows. It workds quite well and probably should be used more.

Another oddity or even inconsitency is that the context page will be returned to when the next action through a topic form or a POST service form is commited (= the Ok button is clicked) but not if it is cancelled (= the Cancel button is clicked).