Fix historyState bug with tg-remote

[qq99]

Fixes #96

If you were to call Turbolinks.loadPage directly (bypassing Turbolinks.visit), rememberReferer would not be called. tg-remote does exactly this via Page.refresh and supplying an xhr in page.coffee.

This PR duplicates a call to rememberReferer, but should have no effect in the Turbolinks.visit case since it's just performing the same thing twice. It's feels a little unfortunate that it had to be duplicated

I think that this is a proper fix because:

• if you navigate from page A > B > C without this patch, a tg-remote that didn't result in a redirect would have B as the referer, and re-push C onto the stack to result in A > B > C > C
• a partial replace should probably care about its referer much in the same way that a regular navigation cares about its referer

I've tested it out on my own project with the back & forward buttons in these scenarios:

• regular navigations
• tg-remote with only an action (aka xhr but no onlyKeys)
• tg-remote with an action and refresh-on-success (xhr + onlyKeys)

Also good for testing is the example app (added a new button + test for this kind of behaviour)

Don't merge: still need to fix:

• tg-remote GET where you want to replace parts of the page and update the URL in history
• tg-remote GET where you want to replace parts of the page and keep URL as it was (no history altering)

cc @Shopify/tnt

[qq99]

Closing this, too old, forgot what I was doing with it exactly.
Lives on in #156