make merging scenario into a real test
add another test for merging but going the other way.  this actually fails.
throw argument parser errors when in acceptance test paths, those should still fail tests hard
teach `mdm update` a `--strict` option, allowing to fail on hash mismatches.  use it to make a test fail reliably instead of generating warnings.
attempt to throw another wrench in the works by randomly nuking parts of working tree during a merge status, this appears to be fine
start all the merge scenarios with master checked out and deps synced to there
skip the usage hash check on update when in mid merge.  this fixes spurious warnings when using `mdm update` in some merge conflict resolutions.

I'd like to restrict the set of accepted hashes to ones from refs involved in the merge.  But, there's nothing to really say you're wrong if you do a manual merge resolution where you take a new version entirely.  A little wild for my tastes maybe, but I can't tell you it's wrong.  So even that limit might be inappropriate.

Then again, I guess that's a general problem with that warning message.  If you update the gitmodules version spec manually (i.e. without using alter) and use mdm update to fetch that version and then go through the git-add flow to pick up the hash change, you'll get that warning, and in the context of this flow, you know what you're doing, and the warning is wrong.  So that's awkward.

Maybe adding some sort of "--do-changes" flag that says you want to take the changes?  That's out of line, though.  The update command isn't responsible for making changes to the parent repo, ever.  Maybe all this stuff should be in the alter command.  That's a little nerve-wracking in its own way, though, as I have a patch staged right now that would make the alter command simply reject use during states like a merge.  So this will require more thought.