tag patch level release

[alerque]

In order to fully resolve #68, we need a new tagged release. Only then can distro packaging actually be reproducable and not require backporting some of the work done in master to even compile.

This PR includes the necessary manifest and lockfile changes to release, but doesn't actually tag it.

• After merging (rebase or squash is fine to not introduce a needless merge commit) whatever the HEAD commit ends up being should be tagged and the tag pushed to the repo.
• Then the tag should be marked as a GH release (notes for that included below)

• That should cause an automatic publish to crates.io, so after releasesing the last thing to do is check that the publish happened correctly.

---

• Add reverse order option
• Correct panic handling to not mess up terminal
• Add debug logging
• Refresh dependencies
• Include synced lock file for reproducability

[peso]

I would like to see a changelog as well.
I think such a log is easier to read if it follows a standard form, for example https://keepachangelog.com/en/1.1.0/

I realise making a full change log is more work, so for a patch-release like this, it would be ok to simply describe what happened since the last release.

[peso]

@mlange-42 you have release permissions, please take a look at this.

[alerque]

I already included notes for the GH release, those could be stuffed into a ChangeLog too. Even better (but the subject for a new release) I would be happy to setup a changelog if the project would adopt the Conventional Commits spec or some other normalized commit formatter such that git-cliff or another tool could be used to automate the process.

---

Edit: The changelog discussion should probably be contained to the relevant issue on git-graph and this project should just follow suit.

[peso]

Lets move on. The change log discussion is not that important.