David Brochart

Or maybe `enabled_middlewares` instead of `register_middleware`, since we already have a `enabled_plugins` option to enable a plugin as a whole, and plugins already register their middlewares with `register_middleware`.

Actually we are going to use [Asphalt](https://asphalt.readthedocs.io) instead of FPS in Jupyverse (see https://github.com/jupyter-server/jupyverse/pull/277), so I'm not planning to maintain FPS anymore.

Now looks like this. Websockets are listed at the bottom with a red background for the paths (warning for some potential security issue). 

We discussed that with @SylvainCorlay, but the point of this PR is making it mandatory to display the API, so that you don't allow e.g. websockets by mistake. If depending...

> I don't see the point of displaying the API in the console at server start-up except for development when you need to check quickly if everything is correctly implemented....

I agree with that. This PR needs access to some of FPS's internals, so I guess we should provide an API to expose them.

This last commit implements (the beginning of) a dashboard, as an FPS plugin. It currently only shows the API summary. The approach here is to keep FPS as an application...

Actually I'm realizing that the dashboard doesn't need to be an FPS plugin. Maybe it should live in the jupyverse repository, since it will probably be specific to Jupyter.

This PR now only consists of adding a `show_endpoints` option that logs the HTTP and WebSocket entpoints. The jupyverse dashboard will consume this information.

@adriendelsalle OK to merge?