Versioning for 3p libraries

[m-nash]

Clear and concise description of the problem

It would be nice to have the ability to indicate which versions were "preview" versions and which versions were "stable" versions in the api version enum in tsp. Today Azure uses a specific convention for versioning of date or date-preview so its easy to parse this and determine which versions fall into which category. Given how diverse versioning schemes can be across organizations it would be good to have the author of the spec indicate this directly into the spec. This would give any consumer the ability to filter out versions they may not want.

We also need a way for customers to be able to specify whether they want to include or exclude preview versions. TCGC today has a helper method, but the question is how / when do you decide to call it? It feels like customers need a compiler flag to indicate this so it can be passed down through the emitter then to tcgc to produce the desired outcome.

Checklist

• [X] Follow our Code of Conduct
• [X] Read the docs.
• [X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[markcowl]

• use semver for now
• how to specify a range of versions, latest GA, latest preview, at compile time

[allenjzhang]

The minimal to do is to allow compile a specific version. With that, user can have full control and specify whichever version needed via CLI.