This is another approach to avoiding the need to close a dialog twice.
The idea is: If the current urlHistory item contains &ui-state=dialog, but the current page is not a dialog, then no hash change is made and no urlHistory entry is created when changePage loads a dialog into such a state. IOW, the state is reused.
Note that the first commit of this PR (851fad0) is also useful for the popup widget, because it fixes a silent problem that's currently present: The urlHistory is moved forward to an entry of type &ui-state=dialog when the user clicks "Forward" towards a location that is no different from the current location except for &ui-state=dialog, but it is not moved back when the user clicks "Back" from such a location.
The popup widget was implementing its own version of this move-urlHistory-back-from-a-dialog-state, but putting it in navigation is better, because it helps fix #2656, and it also helps reduce the extent to which popup has to dabble in the navigation.
I ran the unit tests on this PR, and the unit test which previously failed, namely "going back from a dialog triggered from a dialog should result in the first dialog", did not fail with this fix.
[navigation] Keep urlHistory in sync with browser history even when m…
…oving to/from a #&ui-state=dialog link via Back/Forward buttons
[navigation] Do not change hash nor add history entry when displaying…
… a dialog at a history entry that already has dialogHashKey -- Fixes: #2656