Provide a way to render the spawn form when the user's default server is running

When a default server is running for a user in Jupyterhub, any new request to /hub/spawn gets redirected to the running server. This causes fancy-profiles permalinks to break because they depend on the spawn form being rendered to load the fancy-profiles ui. related issue: https://github.com/2i2c-org/jupyterhub-fancy-profiles/issues/164

Proposed change

@yuvipanda in https://github.com/2i2c-org/jupyterhub-fancy-profiles/issues/164

The way out of this is to use named servers, so each permalink can have its own server. But how do you choose the name? And how do you handle clashes of the name? If the user clicks the same URL twice, if it has the same name, you're back in this behavior again.

We had the same problem with JupyterLab workspaces a while back, and the solution was to add a feature to JupyterLab to autogenerate them! https://github.com/jupyterlab/jupyterlab/pull/5950

So let's implement a similar solution here, in JupyterHub, that autogenerates new server names? That will allow us to make links that will consistently show the form each time they are clicked.

It does mean you'll have some running servers, but the idle culler can take care of them.

Alternative options

An alternative option could be to add a new hook that prepocesses spawn options from queries, similar to what's proposed in https://github.com/jupyterhub/jupyterhub/issues/5101#issuecomment-3079771837. This hook could also decide whether to spawn a server or render the form, and optionally set server_name. That would let downstream users like fancy-profiles define a hook to force a form render or boot a new named server, fixing this issue while also enabling the use of proper query parameters in fancy-profiles as described in https://github.com/jupyterhub/jupyterhub/issues/5101.

Who would use this feature?

This would unblock a major usability gap in fancy-profiles https://github.com/2i2c-org/jupyterhub-fancy-profiles/issues/164