Document our policy for minimum supported Rust versions and when they can be bumped

[sgrif]

This has been discussed internally some, but we should figure out the right place to document it. Last time we discussed it, we decided the following:

• Bumping the minimum Rust version is not considered a major breaking change.
• The minimum version should only be bumped if we have a good reason
  • Convenience/cleaning up code is not a good reason

I think we should also add to the policy that we will not bump the minimum Rust version in a patch version of Diesel.

/cc @diesel-rs/core Does that sound about right?

I think we should probably document this in two places. One for users, and one for contributors. For the user-facing docs, perhaps the top of the changelog is a good place to document it? Right after where we specify our semver policy, we could add: "Increasing the minimum supported version of Rust is not considered a breaking change, but it will only be done in major or minor versions.".

For contributors I think we need to say something like "It is ok to increase the minimum supported version of Rust, but only if it is required to implement your feature. If it is possible to implement without relying on more recent features, you should do so". I have no clue where we'd document that.

We should also probably figure out what our current minimum supported version is and add it to the test matrix (maybe only check that things compile, don't need another full run)

[tcmal]

It seems like this is already being done with nightly-2018-02-02, Just tried compiling with nightly-2018-02-01 and it failed with can't find crate for 'rustc_const_eval' (clippy-lints).

[sgrif]

That's an irrelevant error, the version of clippy we use is tied to a specific nightly, and isn't expected to work with other versions.

[tcmal]

Ah, my bad.