Add healthcheck config opiton

[erithmetic]

Note: this is only compatible with docker-compose v2.1+

And that brings up an interesting question: do we want to start being smarter about how compose_yml handles docker-compose.yml versions? That is, instead of having the v2 module support 2.0+, have separate modules for v2.0, v2.1, v3.0, etc?

One idea here might be to add a compose_yml::File module that can intelligently load whichever version of File we need for the version specified in the yml file.

[emk]

Yeah, the big design decision here is how to represent the different versions of the format. For example, should all versions automatically convert to the newest version when loaded? One catch is that the deserializer and the in-memory representation are tightly interlinked.

One possible idea would be to implement compose::v2::File, compose::v3::File, etc., and then have impl From<v2::File> for <v3::File>. There could be a compose::common for lower-level things which are used by many versions, and it would probably be OK to support v3 syntax extensions in some parts of v2 files to avoid massive code duplication.

Unfortuntately, doing this right will probably involve studying the differences between v2 and v3 very closely.

I do think that v2 should probably just support v2.1 features, without worrying too much about which version: the user used. That's the easiest short-term fix. We could just always output version: "2.1" and call it good.

[erithmetic]

One catch I just found is that compose 2.1 didn't have the start_period option for healthcheck. So we may want to: a) go straight to 2.3, or b) start working on separate implementations for each compose version (2.0, 2.1, 2.2, 2.3, 3, etc.).

I'm leaning towards (b) because compose 2.3 requires docker CE 17.06.0, the first release of CE from Sep 2017 and I imagine there are some people who haven't upgraded to CE yet.

I'm going to play around with defining a 2.1 next to 2 and see where that leads me.

[erithmetic]

I mean, ultimately, my sense of perfectionism would like to see this crate intelligently handle all compose versions.

[emk]

My desire for simplicity would like to read most versions, but only output v2.recent. For now, version: "2.3" output everywhere would be fine. Amazon has upgraded, and so has Faraday. I'm assuming that a 2.3 parser can handle all previous 2.x versions tolerably well.

Basically, I think supporting each of the minor versions separately is too much work and nobody will ever care. I might be wrong, but until somebody complains, let's keep it simple.