Make unstable features explicit with a cargo feature

[sunjay]

We have things in our API that are unstable. Some examples include:

• many methods on Drawing
• everything to do with events

We should make it impossible to use these accidentally by forcing people to use a cargo feature called "unstable". This feature will be disabled by default.

We should make sure that docs.rs still shows these functions and that we have some documentation in each of them to indicate that they shouldn't be used.

One day we might be able to get a working #[unstable] attribute, but until then this will have to do.

• Mark Event as #[non_exhaustive]
• Make sure the test feature can't be used without the unstable feature since it isn't part of our stable public API (use the compiler error macro)

[maxdietrich]

Hey there! I'll take a look into this

[sunjay]

Thanks! Please let me know if you have any questions. You should be able to find all the functions that are explicitly unstable by looking for the word "unstable" in the code. Everything in the events module is unstable because I still haven't figured out the best way to do that without coupling us to the windowing library we're using. (Right now we re-export types from piston). I don't know if I've documented that explicitly yet, so feel free to just add the cargo feature and annotate the functions that are explicitly unstable.

[sunjay]

The rewrite in #173 marked the events API as unstable and made it private when the unstable feature isn't enabled. Part of the work before v1.0.0 is released will be to go through and figure out the minimal stable API for the turtle. The less we commit to, the faster we'll finally be able to release a stable version. (e.g. many Drawing methods and many methods on Color probably don't need to be stable for v1.0)

We can of course make things stable quickly after that initial release, but it would be better to keep some APIs unstable until people actually get some experience with them.

Another possibility I'm considering is doing what nom does and releasing a new major version every year. That we can stabilize just about everything and break as needed every few years.

Still needs some thought before I make the final decision about what we're going to do.