Bump newly release components to their next -dev version

[Blacksmoke16]

Are trying something new in how I handle component releases by following https://trunkbaseddevelopment.com/branch-for-release/.

This PR goes thru and updates the version of the newly released components to their next *-dev version such that if they're installed on the master branch you can tell its not the same release as whats currently live.

It also allows merging breaking changes in prep for the next minor version, while then being able to release backwards compatible changes as patch releases on the current release/major.minor branch.

[Blacksmoke16]

Currently blocked by crystal-lang/shards#572.

[Blacksmoke16]

So in light of crystal-lang/shards#572 and having done a few patch releases since I started trying out this new release methodology; I think I'm going to go back to how things were.

Being in a pre-1.0 state makes it a bit more clunky than they need to be. Only the latest minor version is supported, so there is less of a need to support multiple branches of the code. Using this method also makes it a bit annoying to release patch versions due to needing to manage the the separate branch for essentially no reason.

The primary reason for trying it out was to safeguard against the case where there is a serious bug that needs to be released ASAP, but one or more other, possibly breaking, changes were already merged into master. If this scenario were to ever happen, I could just create a release branch off the first minor commit, cherry pick the bug fix to it, and release from there. Basically exactly the case pointed out in https://trunkbaseddevelopment.com/branch-for-release/#late-creation-of-release-branches.

Having the version of each component be a -dev version was also a nice perk, but given that bug and the fact that pinning to a specific commit between versions is not that common of a use case it's probably not worth the hassle. It can still be done, and may include breaking change(s), and there won't really be a way to compare_versions around it.

HOWEVER, while I'm typing this out I kinda just realized that I could just set the VERSION constants to use the -dev version while keeping the shard.yml version the same. This would allow compare_versions to work, while keeping shards happy as a decent work around for that bug. But I shall have to dwell on if that's even worth doing due to the previous argument in the last paragraph. If so I'll follow up with another PR.

In the mean time going to close this, should also write up something more official for documenting the release process/versioning semantics.