Don't change anchor links to use the history API if the router doesn't have a match

[jbuckner]

The use case for this is integrating router-slot into a server-side routed web app where we're proxy-passing from the same parent URL. ie: foo.com/about and foo.com/products where /about is using router-slot, but /products is not. Anchor links to /products will currently try to be handled by router-slot because it's a relative link, even if you don't have a route for it.

With this change, if you don't have a catch-all route in router-slot, it will allow the browser to redirect the link to the server-side routed /products URL.

If the app has a catch-all route, it will still be handled client-side.

[jbuckner]

Hmm I didn't account for when there are multiple router-slots on screen. With this PR, it would put multiple click listeners on the window and only respond to the router that attached it. I think this can be solved by only attaching it to the top-level router. Testing this idea.

[jbuckner]

That was an easy fix. Now I'm only binding the anchor handler in the root router so we only get one click handler and since it's being used to determine whether the route should be handled or not, the root router should be the last in line to make that determination if the route can be handled.

[christophe-g]

@jbuckner - great, many thanks for this.

Actually, I favored this router mostly because of the way it manages nested router-slot. As I have some parts of the application that can appear under different root path, I'd need ways to write relative ROUTES (without any ref to a route prefix).