Conform to SemVer & add beta release

[smartin015]

I'd like to avoid post-release excitement like that of #14. Now that ownership has transferred, I plan to improve release stability by adopting a more formal process.

Per https://semver.org/:

Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it SHOULD be precise and comprehensive.

The API as declared is currently implicit (see #10). Handlers meant for external usage will be marked as such, and internal handlers (not to be depended upon) will also be clearly labeled. Any deprecation will be marked as a minor version bump, followed by a minor version bump when the final API is decided and a major bump when deprecated endpoints are removed.

Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version... A pre-release version MAY be denoted.

A release channel branch will be set up, and beta users directed to it via the OctoPrint package manager. Releases will soak in the rc branch for some period of time (2 weeks? a month?) before being formally released. Real releases should be delayed if an issue is created from a user using the rc branch.

As part of this issue, I'll also update README.md with details on the release cycle.

[smartin015]

Created 1.4.2rc1 in the new rc branch which deprecates some implicit API methods, while documenting others as public (see #24).

Candidate releases are already configured in __init__.py, so at this point we should be good to close this out and continue development in the other issues.