temp: collect observations

Let's create separate issues from this list once we discussed them a little bit @zephylac. If you'd like to be involved too, we can see which ones who tackles:

- [x] support newest Python versions 3.7 & 3.8. Problem I could figure out so far: `gunicorn` needs to be updated to `>=19.9.0`, maybe `,<20.0.0`, as there's been [conflicts](https://github.com/benoitc/gunicorn/issues/1823) from 3.7 on (#79)
- [x] move away from `imposm` since deprecated since a long while (#80)
- [x] Update project to work on newest packages, most notably `Flask>=1.0`, which also means `Werkzeug>=1.0` (#81)
- `Dockerfile` and template docker-compose.yml can be improved:
- [x] Use a Python base image
- [x] has a lot of unnecessary RUN statements making the final image huge
- [x] Use configs and OSM file as build ARG and keep exposing via volumes, so that we could host the image on dockerhub/other registry, see [ORS docker](https://github.com/GIScience/openrouteservice/tree/development/docker) as example (#82)
- [x] take `tests` out of the main package: can have very undesirable side effects otherwise as the root `__init__.py` is executed when running the tests (#83)
- [x] more proper error codes: right now all is 500, even when most are user input errors, i.e. rather the 4xx family (#84)
- [ ] add test for MulitPolygon API request
- [x] make README more readable in terms of structure etc
- [ ] `area` checks to determine if the request exceeds the server limits are done in `EPSG:3857`, which should ideally be a global equal-area projection like Mollweide
- [ ] the response type had a breaking change when you introduced `MultiPolygon`: now they're all lists of GeoJSON `FeatureCollection` where I don't really understand the point of. It's all the same `geometry.type`, so a list of `FeatureCollection` is pretty much an anti-pattern. Why not wrap all features for all polygons (if MultiPolygon) in a single FeatureCollection? If you really need to relate the polygons of a MultiPolygon to the index in the response list (only reason I can think of) then doing a multipart to singlepart conversion and requesting with single Polygons makes more sense to me. Can we please revert that again?
- [ ] ~~remove all user-settable files from git and provide maintained template versions of them: so we don't accidentally commit our passwords and stuff~~
- [ ] ~~slight changes to make the project more accessible: move `ops_settings.yml` to the root of the main package, remove `server` folder (redundant when tests are moved)~~

Optional:
- [x] use a proper dependency manager: I'm in love with [Poetry](https://github.com/python-poetry/poetry). Super easy to use and million times better than any other.
- [x] Try to incorporate `tox` to test multiple Python versions easily
- [ ] Introduce linter, e.g. `yapf`
- [x] improve testing framework: right now, every single test will create dbs, import data and drop dbs (#96)
- [ ] lots of data duplication in the request handlers in `views.py`, which could be avoided, as that's a potential performance drain