Release 0.2.0

[RunDevelopment]

This PR prepares for the next release. Some of the changes since 0.1.0 are necessary for image-rs/image#2461, so a new release is in order.

I bumped the version and wrote the change log (with the assumption that #66 is merged as is). I also changed the format and file name of the changelog to be more similar to image's changelog.

I already did a cargo publish --dry-run and everything looks to be alright.

To do before release:

• Merge Add support for row pitch in ImageView and ImageViewMut #66
• Add release date to changelog

[RunDevelopment]

@fintelia Since this is the first "real" release, I followed the workflow you outlined here and made a release PR. But from here on out, I have a few questions:

1. Who else should I tag for review? I tagged just you for now, since you are the person that helped set everything up so far and my main contact to the image-rs org. However, there might be others in the org that have an interest/stake in this. E.g. I saw that @ 197g (not pinging yet) merged 2 of my PRs after you reviewed them.
2. Who/what publishes the release. Do you use an automated GH release workflow or is it someone running cargo publish?
3. Git tags. Who should be creating/pushing them?

I'm asking not just for now but also for future reference. I want to write all of this down so everything goes smoothly next time.

[197g]

1. For reference, I've noted my own release procedure down here: https://github.com/image-rs/organization/blob/master/TASKS.md#release-procedure fintelia prefer to release on the merged commit instead which in the end. There are arguments for both ways, we can't atomically merge and release unfortunately. As long as the release tag points to the commit which it is based on and that commit was cleared by CI I don't have much of a preference except habit.

2. No, I'm pretty strict on not putting any of my credentials on Github Actions. There's been, unfortunately, a number of security holes in the past where some actions could have introduced wormable vulnerabilities. Fortunately none that affect us, but just a risk I don't need to take. Until crates.io accepts scoped credentials or an otherwise easily repudiated token there's no compromise I'm willing to make for convenience. (The system of my dream would have the ability to authorize the release action itself via a signature with a hardware key as in WebAuthn assertions).

3. Whoever runs cargo publish, that way they are more easily in sync with the commit that was published.

Hope that answers most of your questions.

[RunDevelopment]

Sorry for the delay and thanks for the response!

1. That document is quite helpful, thank you! (It should probably be updated, though. I don't think any repos still use Travis.)
2. That's a shame but very understandable.
3. 👍