Remove unused future dependency (again)

[musicinmybrain]

See #61. While that PR was merged, it ended up having no effect because a commit merged back from master reintroduced the future dependency to requirements.txt.

[lbeckman314]

Ah, thank you for catching this (and apologies for the regression) — we will review our development flow to ensure that all features are not overwritten with any future merges or rebases. Thank you @musicinmybrain! 🕵️ 🔎

[lbeckman314]

Overview ⚙️

Previous PR: 🔁

• 3e4230d

Commit reintroducing dependency: ❌

• 6a03539#diff-4d7c51b1efe9043e44439a949dfd92e5827321b34082903477fd04876edb7552R2

Next Steps 🌀

Favor rebasing over merging when updating feature/fix branches ahead of a merge to main (or whichever "target" branch you're using) — review what changes are actually being committed ✍️

Additional Resources 📚

• https://stackoverflow.com/questions/28509322/git-merge-causing-regressions

Why do you merge master into feature? Your feature branch should be an isolated set of commits representing your change. As soon as you merge master into feature you've 'polluted' your commit.

If you needed a change committed to master after you branched your feature, you should use rebase. Think of a rebase (in this sense) as making your branch again, right now, with the commits you've already made on that feature branch.