Optional lazy loading of C dependencies

[sgrif]

A common source of questions in gitter and issues here are people who write cargo install diesel_cli and don't have all the backends installed. This was less of an issue when we only supported 2 backends. It's becoming a bit more of an issue with 3 (though I still think the situation is better than the alternative of having cargo install diesel_cli not work, and require backends to always be specified).

What I'd like to do is optionally allow our C dependencies to lazily load the dylibs, and not need to be present for linking. That means that you'd only see an error about mysql if you tried to run CLI with a MySQL URL (and we can probably provide a better error message than the linker is providing). I'd like to keep the footprint on this small, as I don't expect anybody to use this functionality besides Diesel CLI.

[sgrif]

I think this is one of the bigger 1.0 blockers. I can figure this out if needed, but if there's someone with more experience in this space we would love a PR for this

[killercup]

Just talked to @skade who's now searched for and found the cargo install diesel-cli --no-default-features --features "postgres" incantation three times. I was about to open an issue to add some info on diesel-cli's feature flags to its Readme file, but it turns out they are just to enable backends (or clippy) and this issue here will make these docs useless anyway.

[skade]

Would it also be possible to also ship diesel cli as a binary? For example, half of my hefty heroku build times are just building the CLI.

[sgrif]

@skade Are you using https://github.com/sgrif/heroku-buildpack-diesel ? If so just add a .diesel-version file to the root of your repo and the CLI build will be cached.

[sgrif]

This isn't happening for 1.0