Add document detailing release strategy for libraries

[nathan-weinberg]

Resolves #124

[dhellmann]

We spent a lot of time describing release "models" for related projects in the OpenStack community. The document describing those models might be interesting reading for folks thinking about the same topic for InstructLab.

A few things to consider that aren't mentioned here:

1. It's harder than it seems to make the version numbers of the CLI and libraries line up exactly and makes things more confusing to users and rebuilders. I recommend not even trying.
2. Versioning schemes like SemVer can help signal when a new release has breaking changes, but it's still better to make releases backwards compatible as much as possible to ensure adoption of new releases.
3. It makes it easier to reason about release series if the release branch is created from a tagged commit. That can be a .0 release or a release candidate release.
4. For libraries, no one can easily consume release candidates because they aren't installed automatically, so over-using them will make things harder, not easier.

[markstur]

see comments

[RobotSail]

This is all very reasonable and will help out with broader communication across different groups. LGTM.

[nathan-weinberg]

I am going to merge this given the two approvals and amount of time it has sat in the queue, if anyone wants to iterate on these policies feel free to open up a followup PR for discussion