Merge branch 'dev'
release version v2.10.0
Apply the SystemReader fix statically when the Mdm class is touched.

Making this an action performed on classload time makes me itch.  I'd be happier with the capability to apply this conditionally per repo.  But, it's a static property in jgit, so I've really not much choice.
Start refactoring the giant call method in MdmReleaseInitCommand.  Planning to split all the commands out into several phases, with at least a parse phase and a call phase that's on the interface for all commands, but with other argument input methods per command so testing can use an API that's closer to ground than feeding in string arrays to the args parser.
Add a validate phase, separate from the parse phase.  This method will not prompt for input as the parse phase is allowed to, and so would be called by unit test code, and is responsible for defaults and validation that will not look at user input (cwd and the parent repo excepted).
Introduce a layer of indirection in exception handling so I can mark error cases that I consider to be well known.  At the end of the day, I'd prefer that users of the program never have any real reason to realize that it's written in java -- and certainly not because of an IOException dumping stack if you pipe in an empty stdin.  I'll still dump stack for now if there's an exception not wrapped in this layer, but eventually that might also get wrapped in a catch block that logs the full stack to an error file and only shows the short message to the user.
Move argument parser setup out to its own file.
Extract mdm version number from the manifest instead of hardcoding it.
Merge branch 'master' into dev
Refactor more splits into the MdmReleaseInitCommand.call() method.
Introduce more error types.

MdmConcurrentException seemed like a good idea at first; not sure if it actually is for say NoHeadException -- there's a whole class of throwing where I'm working on a repo I just created or already verified the state of, and it's thus tempting to lump possible irritations under the MdmConcurrentException type (they are only possible if someone is running rampant over the filesystem concurrently with mdm's working, right?), but I'm not actually sure how helpful that will be semantically.
Chain an MdmRepositoryStateException into an MdmConcurrentException if that's contextually reasonable.  This ends up with sane error messages at the top level, so I'm satisfied with it.
Create error class to mark unrecognized problems (i.e. the type system says it's possible, but it's not familiar enough yet that we can give helpful suggestions).  Now that commit call in MdmReleaseInitCommand we've been working on only has one MajorBug throw, and it's for an actual compile-time impossible problem, which is as it should be.
Log any errors that we don't have wrapped in a human message to a file instead of dumping stack to the end user.  (Unless the cwd is unwritable; then dump stack on the user because what choice do we have.)
Refactor out makeReleaseRepoInitBranch method from MdmReleaseInitCommand.call(), update more exception passing.
Move the phase of release-init that parses remotes for submodule mode up to the parse function and to use fields instead of local context in the call method.
Finish refactoring out chunks of MdmReleaseInitCommand.call().
Fix problem with linking submodule release repos into parent if the path is non-default.