Remove backend features. Add a crate for each backend. Add a cargo workspace to the top level. Update dependencies.

[mitchmindtree]

This is a follow on from @Abendstolz's work in #1203 that makes a lot of small tweaks and creates a cargo workspace.

This is an important step for #754 as it moves conrod's core slightly closer to being publishable as a 1.0, as most of the instability these days lies within the backend specific code. That said, my primary motivation is so that I may go ahead with rebasing, tweaking and merging @Abendstolz's following PR #1204 that adds support for vulkano as I will be needing it for a downstream project.

All features have been removed. Instead, we now have conrod_core, conrod_gfx, conrod_glium, conrod_piston and conrod_winit crates.

The examples are now in each of the backend crates for which they were created. Although they are slightly less visible now, this has simplified them a lot as we no longer need a lot of scary feature-checking code in them. It also makes it a little clearer which backend is used by each of the examples. Chapter 2 of the guide has been updated in accordance with the change in how examples are now run.

This also applies the dependency version updates by @bvssvni from #1214 along with updates for winit and glium.

Merging is currently pending glium/glium#1715 as the latest published version of glium uses a version of winit that is 2 versions behind and is incompatible with the conrod_winit event conversion code.

Related to #754.
Closes #1183.
Closes #1203.
Closes #1214.
Closes #1217.
Closes #1219.

[bvssvni]

This will make maintenance much easier! Also makes it easier to iterate on the backends without having to release new versions of Conrod.

[Abendstolz]

Great stuff, thanks for taking this up again. To be quite frank it felt (and to some extent still feels) as if Conrod was dead.

[OtaK]

Amazing! I've been holding back publishing some of my work on Conrod for this exact reason; the inability to make a small crate that would make use of the core without pushing a whole PR to conrod itself was really really putting me off (also meant bringing optional deps, features and all the complexity that was going with that).

Cheers!

(Also, on another note, we were really successful in making our embedded prototype with Conrod, and I'm currently exploring the likes of Azul & co. At least I know conrod does the job for GUI stuff, so if the others don't fit our use case, I might come back to Conrod :) )

[mitchmindtree]

@OtaK thanks for sharing! In case you're interested, there's still a small amount of room for further crate separation, namely:

1. Splitting out all non-primitive widgets into a conrod_widgets crate. This is another source of instability as the widgets constantly need tweaking and slight behaviour changes in order to satisfy different folks' needs.
2. Split the guide out into a conrod_guide crate (while ensuring all examples can still compile with when running cargo test).