- When a request matches a static routing "exclude" rule, it's directly
forwarded to the asset worker.

- When a request matches a static routing "include" rule, it's directly
forwarded to the user worker.

- Otherwise, previous behavior takes over

This also adds a new analytics field (double6) for what routing decision
was made

vitest yelled at me and told me this should be awaited and may error in
future releases

When the Router worker has static routing, the check against
"Sec-Fetch-Mode: navigate" is unnecessary. We have explicit static
routing to indicate whether or not we should go to a User worker or
the Asset worker, and should not try and guess via usually-set browser
headers

This adds a new parameter to unstable_canFetch RPC method, which should
be fine for backwards compatibility, and can be extended in the future
if needed. This was necessary because the Asset worker checks the
Request headers for Sec-Fetch-Mode to indicate if it can serve an asset
(including an index.html or 404.html page based on not_found_handling),
but static routing is only provided to the Router worker. Thus, we need
to pass more information over RPC

Now that we're not providing this configuration via _routes.json, we can
relax some of the configuration. Much of this happens on the backend,
but some field names have been changed ("include" -> "worker",
"exclude"->"asset")