Document upgrade strategy about the-littlest-jupyterhub

[choldgraf]

Plan is to include this in v0.2, since we don't necessarily want to "freeze" an upgrade pathway yet until we see more usecases out of TLJH.

[yuvipanda]

I think the general upgrade strategy is to run the installer again, and that 'ensures' everything to where it should be. This means we need a way in the installer to:

1. Tell what the current version is
2. Refuse to upgrade if it is unsupported
3. Upgrade various components as atomically as possible
4. Always have option of 'blow everything away and re-install it' without losing any user state.

[nsurleraux-railnova]

If anything, I would love to have my installation backed up so that if an upgrade borks it, we can always restore it to the latest working state. (It could be automated or part of the documented upgrade process).

In the requirements-user-env-extras.txt file, it is clearly written that TLJH won't upgrade those libraries if TLJH is upgraded. The documentation should explain why it won't be upgraded (as users can upgrade/downgrade them). I think it would be reasonable in the upgrade documentation to have a table with the versions of the TLJH against the recommended versions of the libraries in the user env.

(EDIT: https://github.com/jupyterhub/the-littlest-jupyterhub/pull/888/files?short_path=3bd14d0#diff-3bd14d078188074c410028847113ceae68865d0ad5b844a27183ef87fbe2fcc3 seems to already include a table with the user env version upgrade)