Use open-ended versions so that downstream projects can pin exact versions

[alastair]

The new dependency resolver in pip 20.3 fails where previously it just gave a warning. We are seeing the following error in ListenBrainz:

ERROR: Cannot install -r requirements.txt (line 24) and redis==3.5.3 because these package versions have conflicting dependencies.

The conflict is caused by:
    The user requested redis==3.5.3
    brainzutils 1.14.1 depends on redis==2.10.5

To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip attempt to solve the dependency conflict

Because BU is a dependency of other brainzes, it makes sense to make its dependencies flexible so that other projects can pin an exact version.

If this PR works, I will release it as BU 1.16

[alastair]

here's one thing that I'm unsure about:

We have dependencies in BU for things like flask, jinja and werkzeug. As a result of this, I got into the habit of removing them from requirements.txt in downstream projects (e.g. LB). However, a result of this is that dependabot won't give warnings about (last I checked it didn't do transitive dependencies).

Also, because we now have a range here, building LB twice could result in different versions of packages being installed if we don't pin them in LB's requirements.txt.

Any thoughts on how we should do this? I'm tending towards using these ranges in BU, and then adding back in specific versions to LB.

[alastair]

We decided to do what I suggested, and explicitly add dependencies in downstream software (see related PRs)