Cascading flags

Overview:
* Some refactoring to emphasize when a collection is mutated since this is playing a bit on this
* Added flags to apply commands to a super-set of the given target.  I see `-d/--dependents` as a handy way to safely affect dependent containers when doing "destructive operations", and `-D/--dependencies` as a way to easily get one or a set of containers started, no matter where it is/they are in the dependency graph. Combining both allows for targetting the full dependency graph containing the given group/containers (as their might be several independant ones).
 * Poor man's solution to https://github.com/michaelsauter/crane/issues/50 (simpler implementation, same benefit as long as the user keeps track of what's running or not) 
 * (Hopefully) a base for getting https://github.com/michaelsauter/crane/pull/58 right in the future, so that `-s`/`--skip-unchanged` would be safe to use as we could something similar to `-d` internally, within the target group to identify.

Some questions that came to my mind:
* Is it worth giving more granularity for the control of the dependencies (`--linked`/`--volumes-from`) via string variants of these flags rather than booleans? I don't think so - at least I can't foresee any use-case right now.
* Should the new cascading flags care about the state of the "extended" target (exists, runs) ? I think it could be a lot smarter (ignore non-existing containers in `-d` for example), but this would be too much in terms of complexity, both for the user and for the implementation. That can always be done later...
* How does this play out with explicit order defined in the configuration? Good I believe, the implementation should be rather permissive, and should not break if dependencies are missing (which is one use-case for custom ordering I guess). However, these flags only make sense when the dependency graph is well defined, so I see mostly users of implicit ordering using them.
* Would it require some documentation in the README.md? Probably, but I believe the whole dependency stuff would, so I guess this could be done separately in https://github.com/michaelsauter/crane/pull/49
* More explicit name for the flags, maybe related to "cascading" ? Couldn't find any, not completely satisfied wit the current ones :(

I know you're trying to keep `crane` simple, but I don't think it's particularly complex to maintain - most of the pieces required were in place and a lot of additions are actually tests. What's your opinion? Anyway, this is a first shoot at it!
There is currently nothing that prevents a container that was explicitly targeted to depend on an container not listed in the crane config. This was defensive code to avoid a panic if that ever happens. We could leave this out for now and handle this in a central place in another PR if you prefer, your call.