[FEATURE]: Semantic Versioning

[mehalter]

Is your feature request related to a problem? Please describe.
With the new multiplexer functionality and incredible new features being added specifically with terminal integration, it would be great to communicate through versioning if/when breaking changes occur. Plugin managers such as Lazy have the ability to track plugins based on semantic versioning to protect users from random breaking changes that would require their setup to be modified.

Describe the solution you'd like
Use GitHub releases/tags to track the version of smart-splits following the semantic versioning spec. There are also some great GitHub actions that I have seen other plugins use such as release-please-action which help automate this process and ease the added work to maintain version numbers.

Describe alternatives you've considered
The other alternative is just leaving it as it is which definitely works, but adopting semantic versioning would make it easier to communicate to users when breaking changes occur down the line such as changing default options, removing deprecated options, etc.

Additional context
AstroNvim uses (and loves! ❤️) smart-splits and the way our stable releases work are we allow non-breaking updates to plugins that follow semantic versioning. If a plugin doesn't use semantic versioning then we pin the plugin to a specific known working commit for stable releases. This not only would help users that don't use AstroNvim, but it would allow AstroNvim users receive non-breaking updates without the AstroNvim devs tagging a new stable release.

[mrjones2014]

I'm totally into this idea. Some of my other plugins already do so. I just haven't done it here because I had the impression that it had a much smaller user base and haven't dedicated as much time to this plugin as the others, but seems like that's changing, I'm getting more community requests etc.

I had no idea this was used in AstroNvim, that's awesome! That also means that the userbase also includes AstroNvim users, which won't be reflected in the number of GitHub stars this repo has (I use stars as a loose/rough metric to estimate userbase size).

Implementing this I think should be as simple as basically a copy/paste of some GitHub Actions workflows and Makefile stuff from mrjones2014/legendary.nvim.