Do first alpha testnet release

[cornelius]

This is a spin-off of #735 for the first release we do for the alpha testnet (together with opening the code). The release will be a minimal source-only release. We won't offer binary builds. The work which is going into the release is tracked with the 0.1 milestone. When this is 100% complete we are ready to release.

To be done for the release:

• [x] Adapt the version number reported by the client to "0.1.0" (https://github.com/dtr-org/unit-e/pull/945)
• [x] Write release notes. This is a minimal document giving some basic information about what is in the code, and how it is supposed to be used. It won't have a list of changes as it's the initial release. The next version will have a changelog relative to this release.(https://github.com/dtr-org/unit-e/pull/946)
• [x] Generate man pages (https://github.com/dtr-org/unit-e/pull/945)
• [x] Tag the git repository with "v0.1.0"
• [x] Add release notes on GitHub release and mark it as pre-release

[cornelius]

I would suggest to do the release notes following the conventions described at https://keepachangelog.com. This is simple, sufficient for now, and follows best practices.

[cornelius]

Shipped :shipit:

[scravy]

Have a branch v0.1?

[cornelius]

The idea was to just use release tags on master for now and not have release branches. If we need them, we can still create them, of course, but not having them by default makes things a bit simpler and doesn't bloat the repo in terms of branches.

Following our versioning plans we would create release branches with major releases, so 1.0, 2.0, etc. This would be the equivalent to the upstream policy.

As a side note: The naming convention we probably want to follow is to use the v prefix for the tags, but leave out the prefix for the branch names. That makes them easier to distinguish. This also would be in sync with the upstream policy.