docs: Add Development and Releases sections to the documentation

[stinodego]

Changes

• Added a section "Development" with two subsections:
  • Contributing - for now I copied the CONTRIBUTING.md here, but we can extend this with subpages including things like preferred code style etc.
  • Versioning - includes our versioning scheme and I wrote down our policy on breaking changes. I think this is important for managing user expectations going into 1.0.0
• Added a section "Releases" with two subsections:
  • Changelog - for now this points to our GitHub releases, but I intend to set up our CI to publish the changelog to our docs too.
  • Upgrade guide - this should include an upgrade guide for each breaking release.
• Add config file for the Markdown Link Checker, as it somehow is tripped up by crates.io links

After this is released, I will update CONTRIBUTING.md to point to the contributing information in the docs.

[alexander-beedie]

Some near-subatomic grammar tweaks/suggestions from me 🤣

[stinodego]

Thanks Alex - helpful for a non-native speaker like me :)

[ritchie46]

Can we word this less drastically? Maybe that we are more certain about the lazy API, but that the internals may expect more breaking API changes. Also because it is harder to hide the API than it is in python.

[stinodego]

Sure, will change the wording here!

[stinodego]

We don't really have to say anything about the stability of the API. We just need to mention that we don't deprecate things in Rust. I rewrote it to:

Breaking changes to the Rust API are not deprecated first, but will be listed in the changelog.
Supporting deprecated functionality would slow down development too much at this point in time.

[ritchie46]

Alright. Good to go and good addition.