Do not dispatch multiple visit events on redirect visit

[domchristie]

#328 fixed an issue with the window's location in native adapters (hotwired/turbo-ios#30 & hotwired/turbo-android#128).

However, proposing a new visit re-runs the visit lifecycle again, duplicating events, and introduced issues such as #428, #526, #537 & #877.

This pull request reverts the visit proposal, and instead updates the location as part of changeHistory(). (This may not have been doable before #601.) It leads to a simpler followRedirect method that now just updates the visit's location. As such, we no longer need the fix from #563.

Fixes #877

[jayohms]

As mentioned here #328 (comment) this approach is not compatible with with the iOS/Android Turbo adapters and the way that the libraries work. Avoiding a double-visit on a redirect won't be trivial, so maybe there's another way to approach the issue you're experiencing with the double-visit + animation. Most importantly, though, the mobile adapters need the opportunity to see the redirect url and start a new visit.

[domchristie]

Thanks @jayohms, that definitely clears things up.

I wonder whether there might be another way to model Visit proposals? The Visit class seems to be used as a way to trigger a Visit lifecycle, but this can mean different things in different contexts. For example:

1. A standard Visit that navigates from one location to the next
2. A same-page anchor Visit
3. A redirected Visit
4. A Frame Visit (promoted to a Visit using data-turbo-action

Each has different expectations and outcomes, which hints that they could be different classes that share the same API

[domchristie]

Alternatively: https://github.com/hotwired/turbo/compare/main...domchristie:silence_non_rendering_visits?expand=1