Create basic infrastructure for unit tests, in particular to deal with temporary working directories.

This is less than ideal in some ways -- in particular, there's going to be a wholllle lot of instances of new File(.).getCanonicalPath() in test methods to try to pretend we have a real valid cwd.  Integration tests in the future will try to address coverage of this, but I think that will require doing full forking per test, which isn't a great option for unit tests.
Unit tests for some of MdmReleaseInitCommand functionality.
Improve MdmReleaseInitCommand's check for clean area to accept existing directories even if not the cwd but reject directories that already contain a (canonically named) git data dir.
Add more tests for MdmReleaseInitCommand that reach into the object trees to check the release repo result state.
Remove some test methods that seemed redundant (kept just the final one in the series that was a superset of the others), placed some common objects as class fields so I can use methods that produce them as both tests themselves and in composition with other tests, reduce repeated setup code in some tests due to previous, renamed a variable to camelCase because the lack thereof was bothering me.
Add test method to check head refs are in correct place after MdmReleaseInitCommand.
Several more tests for MdmReleaseInitCommand to cover the basics of parent repo state when the release repo is a submodule.
Fix some issues in MdmReleaseInitCommand with canonicalizing paths -- these were irritating problems of the sort that are a non-problem when actually using the program with a real cwd, but show up in tests as a result of the surreal cwd problem.
Refactor build.xml to use path structures instead of strings.  Create compile-test and run-test targets that make junit tests happen.
shifting dependency on lib/junit to version v4.11.

want FixMethodOrder annotation.
adding dependency on hamcrest-core at v1.3.

this is a new requirement for junit as of v4.11.
add the new junit dependency to build classpaths.
Revert "add the new junit dependency to build classpaths." (d54b99f), "adding dependency on hamcrest-core at v1.3." (5a80a0u), and "shifting dependency on lib/junit to version v4.11." (6f475b2).

JUnit's new packaging annoys me, changed the behavior of the eclipse gui plugin, and the FixMethodOrder I was interested in turns out to have a ridiculously useless implementation (it only accepts values from an Enum instead of any class that matches an implementation, which, what, why, I don't even, )
Add some hacks to junit to force tests to run in what we're going to refer to (somewhat leniently) as source order.

This works when running tests from ant, so yay, but interestingly can only find debug information to get method orders from eclipse for -some- methods, which leads to an nonsensical sort result, and I haven't really figured that out.
Make SourceOrderMethodComparator blow up on NullMethodPosition, and OrderedJUnit4ClassRunner make no changes to the existing method ordering in that case.

This leaves the eclipse junit plugin with source order for junit <= v4.10 (I've seen posts years old saying jvms are all going to change to get random method orders returned from reflection calls, incidentally, but I'm not actually experiencing that and going to keep singing on in peaceful bliss), and also works as desired when testing is invoked from ant.
inject a few more headings into the alternatives doc above paragraphs that didn't really match their previous heading.
add more examples of language-emphatic dependency management tools to alternatives doc.
move the 'dodging the problem' section to the top of the alternatives doc, because it makes sense to lead with the most simplistic option, and because it makes sense to cover that one first since other sections refer to it.
lift args parsing in MdmReleaseCommand out to parse method, as in MdmReleaseInitCommand
refactor several environment checks at the beginning of MdmReleaseCommand.call() to their own methods.

I'm finding that at lot of things actually look relatively reasonable to do as static calls.  I'm not sure that will be consistently true, but for now I'm going to go with it.