Don't run clippy if it's not currently available

[Nemo157]

Fixes #6

Unfortunately just using a dated nightly for clippy won't work. As an example nightly-2018-08-28 does include a working clippy, but having the clippy build use that would still cause #3 to fail as the new code will no longer compile with nightly-2018-08-28.

Best solution I can find for this sort of bleeding edge development is to just not run clippy when the nightly doesn't include it, once stuff gets closer to stabilisation then using a pinned nightly might be more doable. This can mean that latent errors that will fail clippy later can make it into master, but those can just be fixed as they happen.

[Nemo157]

@MajorBreakfast if you're happy with this solution I can create an identical PR to futures to fix the issue there as well.

I'm quite disappointed that Travis CI doesn't seem to give any way to have a build dynamically warn rather than just error, only statically allowing the build to fail, but that would defeat the point of using clippy since when it is available and fails it wouldn't show.

[Arnavion]

You can alternatively cargo install it from its git repo if the rustup component doesn't exist. You'll have a slightly higher success rate because clippy sometimes gets fixed in master but doesn't get published (as is the case right now, in fact) at the expense of a much longer build time.

[MajorBreakfast]

Good idea. I think this is a good compromise. IMO it doesn't matter too much that Clippy is sometimes not available because new rules which also break the build might get added. So, it can already happen that code that worked when it was merged breaks afterwards. Clippy sometimes not being available makes it just a bit more likely that we merge code that breaks afterwards.