event.destination should not be an AppHistoryEntry. How should it behave? #97

As I started trying to spec event.destination, I realized making it an AppHistoryEntry would not work very well. In particular, only sometimes would we be able to get the right object identity, i.e. the one that matches up with appHistory.entries() or appHistory.current after the navigation. And, adding event listeners doesn't make much sense. And, the semantics of index were strange.

So we should definitely divorce event.destination from the AppHistoryEntry instances that live in appHistory.entries(), and instead make it a more abstraction representation of the destination. I think reusing much of the AppHistoryEntry properties makes sense, but I have some questions for each of them:

• url: OK, well, this is still obvious
• getState(): this seems fine and useful to include
• key: For push navigations, should key be the future key, or should it maybe be null? This is clearly a must for traverse navigations, and is easy to compute for replace navigations.
• id: should this even be included? Is it useful to make the browser figure this out early?
• index: a few options...
  • Don't include this
  • -1 for push navigations, accurate index for other navigations
  • appHistory.current.index + 1 for push navigations, accurate index for other navigations
• sameDocument: If you call event.respondWith(), should this change, or should it always reflect the "original" navigation? (AppHistoryEntry.sameDocument #70)