Document package and API versioning policies.

[pmconne]

Fixes https://github.com/iTwin/itwinjs-backlog/issues/391.
Incidentally fix bug in README: you can't successfully rush cover without first rush build:ci-ing.

TODO

• Integrate into docs
• Guidelines for iTwin.js devs on how to handle breaking changes, incl when reviewing PRs
• Clean up docs/learning/guidelines/release-tags-guidelines.md

[pmconne]

TypeScript's flexible, structural type system and its compiler's ability to reason about types imposes pretty strict constraints on what we can call a "non-breaking" change. Union types are a prime example given tsc's default rules about unreachable code (which can only be disabled globally).

Plenty more examples here.

[pmconne]

@calebmshafer I can't find much info about how VS Code handles breaking changes in its extension API. The API doesn't appear to be versioned. They "give our best effort to avoid breaking API changes" and "never want to break existing extensions".

They call their beta APIs "proposed APIs" available only in Insider builds and allegedly not permitted to be used in published extensions. These APIs may have breaking changes in new releases.

[calebmshafer]

This looks good to me now.

[jbelevicius]

In the "API Categories" it is stated that "deprecated tag is typically accompanied by information about the package version in which it became deprecated" - this should be noted here as well I suppose.

[pmconne]

True. It's currently an aspirational lie though - nobody has ever actually included version information in a @deprecated tag. @aruniverse suggested we start doing that. Perhaps we need to write a script that will add "3.x" to anything currently tagged as deprecated.