Added a ResourceReader that can retrieve test resource files in nested locations

[drivenflywheel]

Allows decoupling from the default ".dat" file naming scheme and flat directory structure. Primarily intended for use by IdentificationTests that can benefit from more content-representative test file names. Along with PR #555, this will allow IdentificationTests to specify a payload's "expected form" via directory name rather than file name, without explicitly requiring an answer XML file.

With the initial commit, test data files should be stored anywhere below the TestClassName/payloads folder. Answer files (when needed) should be in mirrored paths below the TestClassName/answers folder.

Given the fairly large break with existing convention, I thought it would be prudent to keep this functionality out of the base ResourceReader class so devs would not accidentally select the new methods via autocomplete.

[jpdahlke]

@drivenflywheel is this something we should revisit or spend cycles integrating? It seems helpful for certain situations but I'm not sure where we left it.

[dev-mlb]

Should this class exist in the test package?

[DonResnik]

You could argue either way, but I like it where it is. As a class that supports a test (as opposed to containing tests), it seems reasonable to be in main/util/io.

[ldhardy]

I agree it should be part of the tests jar. I don't know why we would need this outside of our test framework. The conventions it implements are test framework conventions.

[ldhardy]

The unit test that is testing this test utility would live side-by-side next to it. I'm ok with that even though it's a bit unconventional.

[DonResnik]

As a newer user of the API, I like the idea of not have to call everything a .dat file in tests. As a follow-on effort, it might be good to incorporate this into RegressionTest and it's generation of answer files to follow this implementation.

[DonResnik]

code looks good. mvn clean install completed successfully.

[ldhardy]

I was running into several scenarios where I didn't want answer files in xml format. I had input and expected output versus actual output that I wanted to be able to compare in a diff tool in the IDE, as text, or json, or some other pretty format that is human readable and easier to diff. It would be nice if answer files didn't have to use xml extensions to be identified as answer files.