Allow [...rest] params to be optional

[Rich-Harris]

With this PR, /foo/bar would match src/routes/foo/[...rest]/bar, and page.params.rest would equal ''. Closes #751

[benmccann]

/foo/bar would match src/routes/foo/[...rest]/bar

I'm not sure whether that's what I would expect. It makes sense that it's optional when it's last. Less sure when it's in the middle

[Conduitry]

As I mentioned on the issue, I think it's pretty safe to match liberally because you can always limit it with load fallthrough.

[benmccann]

I'm not sure which page I would expect to be evaluated first with fall-through. I can imagine it causing unexpected bugs. E.g. I add a new route foo/[...rest]/bar and then foo/bar unexpectedly loads the new route. I'm unlikely to have visited foo/bar while developing foo/[...rest]/bar so could easily miss this this and not know I need to develop a fallthrough case for it. I sort of think that the better way to support such a case would be to allow programmatic access to the router for the user to add arbitrary regex routes. That would support a wider range of use cases and be more explicit. It seems like there'd be a lot of potential for confusion to do it by default

[Rich-Harris]

I think that's really just a question of documentation. If someone already had src/routes/foo/bar.svelte then it would match first (rest parameters are low specificity). And presumably you're going to be checking that params.rest is valid anyway, otherwise things are guaranteed to break

[rmunn]

I created a route src/routes/foo/[...rest]/bar, and it worked as designed: loading localhost:3000/foo/bar matched the route, with page.params.rest equal to '' (empty string). But it also matched the route localhost:3000/food/bar with page.params.rest equal to 'd'. Details at #918 (comment).