symlinks appear to pose a challenge during cleanup, because the jgit FileTreeIterator appears to have a la-la-la-i-can't-hear-you sort of attitude about them.
move SubrepoWalkTest, it isn't nearly as isolated as a unit test would like to be
implement symlink detection and teach SubrepoWalk about it.  tests for SubrepoWalk now pass.
add another test to make sure we don't have false negatives in case of dealing with an entire parent repo under a symlinked dir
confirm that update command's cleanup of dangling mdm repos leaves normal submodules intact.
bring the test for symlink handling (well, ignoring) up through the actual update command tests.  not quite joy yet because java file apis before 7 remain unbelievably ridiculous.
give up, make the directory exist again so we can see the symlink and the test can pass.

note that this dangling symlink invisibility thing implies our subrepo walk code is probably at least a little technically wrong as well.  practically speaking, i fail to care because the only case it needs to handle specially is when a symlink could make a submodule "appear" where there isn't one... which a dangling symlink can't do anyway.
Merge branch 'cleaning-up-unlinked-deps'
update to stance on transitive dependency resolution.

it's of course still true that a transitive dependency resolution step at runtime will *never* be necessary for someone to *use* a project that has deps spec'd with mdm.

and dependency resolvers have some downsides: they historically do seem to have a tendency to bloat projects (you can't trust your dependency's dependency to not specify fucking junit as a compile dependency, and similarly there are string processing libraries on maven right this moment that rely on both scala-lang *and* jruby in the same breath and no visible sense of irony), and dependency resolve adoption actually tends raise the complexity level of an ecosystem(more tiny jars does not help, if i wanted a smaller binary i'd use a real tree shaker like proguard because That's What They're For).

but all that said, i'm open the idea a transitive dependency resolver can possibly be useful.  or at the very least, as long as they produce firmly pegged and version controlled lists of final, resolved dependencies, then they can't spectacularly damage the ability of a project to ship, which is good enough.
produce more help text when running `mdm -h`.  in particular, call out that subcommands also provide their own help, and also give a pointer to the extended docs online.
get much, much cleverer about hash validity checking during update on a git repo that's in the middle of resolving a merge conflict.  the prior duct-tape fix just ignored the hash check entirely while one was merging; now it properly checks that the hash comes from one of the merge parents.
backfill changelog for the other various recent features and fixes
implement a 'reclaim' feature for mdm-update to give an easy way to update existing workspaces.
emit the full usage and help text when mdm is run with no arguments.
help text touch
minor phrasing changes in changelog.