differentiate between back and forward navigation

[SteffenDE]

Fixes #3536.
Relates to #3513.

Browser history API strikes back (again). Because live navigation shares the id of the view between live navigations, the following scenario could happen:

1. User visits page 1 (state: initial)
2. User patches the page (state: patch)
3. User visits page 2 (state: redirect)
4. User patches the page (state: patch)
5. User uses browser back button (state from 3 -> live nav)
6. User uses browser back button (state from 2 -> PATCH)

In step 6, the user is still on page 2, but LiveView would try to patch the page instead of performing a live navigation. This is only a problem if the two pages use the same underlying LiveView module, otherwise the patch request would fallback to a navigation. Also, we have an unnecessary live navigation instead of a patch at step 5.

To fix this, we now differentiate if we are navigation backwards of forwards and store the corresponding backType in the history state to do the correct type of navigation on popState, which was already mentioned as an idea in #3513.

1. User visits page 1 (initial nav) state: initial

pre-push: update state to {type: "patch"}
2. User patches the page
post-push: push new state {type: "patch"}

pre-push: update state to {type: "patch", backType: "redirect"}
3. User visits page 2 (live nav)
post-push: new state {type: "redirect"}

pre-push: update state to {type: "redirect", backType: "patch"}
4. User patches the page
post-push: new state {type: "patch"}

5. User uses browser back button (popState backType "patch")
-> patch from the patched page back to non-patched page 2.

6. User uses browser back button (popState backType "redirect")
-> live nav from the page 2 to patched page 1

Finally, we can also prevent the unnecessary remount when navigating all the way back properly (see #3335).

[SteffenDE]

Supersedes #3538.