Handle special props ref and key in path and search params

[jtoar]

Closes #5497. When it comes to the router, it's react components all the way down. The router is a react component; routes are react components; pages are react components. We pass path and search parameters to pages as props, so that you can do things like...

const PostPage = ({ id }) => {
  return <PostCell id={id} />
}

(You can also get id from the params context via useParams, but destructuring it from props is more convenient.) When a path or search param is ref or key, there's an issue. If it's ref, the component throws since you can only pass the return of React.createRef or useRef to ref. With key, nothing happens, but the component consumes the prop and you don't get access to it. It's still accessible via useParams, but this isn't super obvious.

This PR stops the hard break that happens when ref is passed. It also stops the router from passing key.

[netlify]

✅ Deploy Preview for redwoodjs-docs canceled.

Name	Link
🔨 Latest commit	9a3e15b
🔍 Latest deploy log	https://app.netlify.com/sites/redwoodjs-docs/deploys/627f7d3ebed86e000806d9dc

[Tobbe]

Should we have a lint rule to make sure no one tries to have a route like /foo/{key}/bar/ or /books/{ref}/authors?

[jtoar]

@Tobbe yeah that seems like the way to go. What should we do if the lint rule isn't heeded though? The router should probably fail in dev right? And in production? I still haven't thought it through

[jtoar]

CI is failing because there's type error on allParams I was treating as a learning exercise