Should we add support for preview releases in language versioning?

We've long expressed a desire to be able to iterate on language feature designs based on feedback, but the current mechanisms we have in place don't provide a lot of scope for this. In particular, we currently move features directly from being enabled only via an experiment flag (and hence very hard to use on a larger scale), to being officially released. With the recent release of extension methods, we informally designated the first release as a preview release, and took advantage of this to ship an update based on feedback. This seems like a valuable workflow. In order to support this directly in an automatically enforceable way, I'd like to propose that we add an intermediate stage to the language versioning proposal in which a language feature is in preview. When a language feature is in preview, the pubspec sdk constraint is required to have a lower *and* upper bound of the preview release in order to enable the feature, and the language version number for the preview release in the `.packages` file is treated as an exact constraint: the file can only be run on that exact SDK.

This would allow us to release a feature as an explicit "preview" release, with the contract being that:
- You can use the feature and publish packages using it
- But you can only publish packages using it if you use a tight SDK constraint
- We reserve the right to change aspects of the feature in the next release (or next `k` releases), which won't break your package, but will force you to publish a new version that fixes any issues and advances/widens the SDK constraint

@lrhn @mit-mit @eernstg @munificent @kevmoo thoughts?