Implement user login

# Goal

Every user (or organization) should have their own account. This is primarily so that they'll have their own set of tile server URLs, ensuring our own compliance with the Terms of Service of the various providers.

## Tasks
This involves quite a few moving parts:
- Mechanisms to register, unsubscribe, change passwords, etc
- Ideally a way to use [OAuth](http://oauth.net/)
- Cookies to keep sessions logged in
- A database to keep track of user data
- Management of secure passwords/hashes
- A mechanism for people to select and/or enter tileserver URLs and save them to their accounts

### Minimum Viable Product
The MVP is nothing more than user login with an admin-provided username and password, without which users don't have the option to select non-free tile server URLs. That's probably only a few hours of work from where the app is now.

### After MVP
The next functionalities needed, in rough order of priority, are:
- User registration so that they can create their own accounts
- Ideally with the rest of the standard suite of account actions, like change password and unsubscribe, though this may not actually be essential as the eventual goal is to move to OAuth
- Mechanism for users to add tileserver URLs, which are only available to them when logged in
- OAuth so that people can use their OSM accounts instead of creating yet another standalone username and passwords
- Public and private asset management, so that people can choose whether to share their AOIs and tilesets

### Resources, Tutorials and Guides
- As usual, [Miguel Grinberg](https://courses.miguelgrinberg.com/p/flask-mega-tutorial) has a great [tutorial](https://blog.miguelgrinberg.com/post/oauth-authentication-with-flask)
- OpenStreetMap [implements OAuth](https://wiki.openstreetmap.org/wiki/OAuth)
- There are [several Flask Oauth frameworks](https://oauth.net/code/python/). Grinberg's tutorial uses [rauth](https://rauth.readthedocs.io/en/latest/) but it would probably be worth a bit of searching and reading to decide if that's the one to use, or if another would be more suited to this specific task
- Tilehuria already uses SQLite3 to write MBTiles files (which are basically SQLite tables full of binary image blobs). However, for a user database it probably makes way more sense to use [SQLAlchemy](https://www.sqlalchemy.org/) because it can work with full-fledged databases as well, though the initial implementation should probably just be a SQLite database for simplicity. Again [the mighty Grinberg Mega-Tutorial](https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-part-iv-database) is an obvious resource.
- I've already begun a partial implementation of [Flask-login](https://flask-login.readthedocs.io/en/latest/). If I remember correctly, I was probably following [Grinberg again](https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-part-v-user-logins)

### Other thoughts
- At some point it may be that we want to move away from storing anything on the local filesystem (certainly if TileHuria ever needs to be elastically scaled that will be essential). So storing the various assets that get written to disk in a proper, [fully-fledged database](https://www.postgresql.org/) would be the eventual way forward. This would in turn make it quite a lot more straightforward to allow users to select whether their input and processed files are public, shared with certain people only, or private. This could be done by keeping records of what's on the disk, or setting some kind of flags files, but that's probably not worth pursuing.

The issue names no files or tests; start by reviewing the partial Flask-login implementation and the Flask authentication and database resources linked in the description. Define completion around the stated MVP: an admin-provided username and password, session cookies, and restricting non-free tile-server selection to logged-in users.

Written by the indexing model from the issue text.