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!
One flag gives you the guarantee that dependencies are included (no error in resolving dependencies in `order`), and the flag gives you the guarantee that affected containers are included (no risk to break a container that depends on something in the target that we restart for example). IMHO, when combined, both guarantees should apply.

If you run in 2 separate loops seeded by the explicit target, the ones included via `--cascade-affected` might not have all their dependencies included (and therefore the dependency check will fail), and the ones included `--cascade-dependencies` will break any other container depending on them if they are restarted.

That's why the documented and unit-tested behaviour of combining the flag is to select the whole graph in the dependency forrest.