Fix FileUtils#urlToFile() on Windows

Under certain circumstances, on Windows, URLs are translated into
strings of the form "file:C:/..." (which the URL constructor does not
like at all) instead of "file:/C:/..." (which the URL constructor
does like).

Let's be lenient on Windows and just accept even the first form.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add a regression test for urlToFile(directory)

Java on Windows really has problems in that department: the default
AppClassLoader is a URLClassLoader whose getURLs() method returns URLs
of the form:

	file:C:/path/to/file.jar

i.e. omitting a slash: it should read

	file:/C:/path/to/file.jar

instead, otherwise, when converted into a URI via the toURI() method,
then passed onto a File constructor, one will see the lovely message:

	IllegalArgumentException: URI is not hierarchical

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add utility class for dealing with platform issues

In particular, it has some classic OS detection methods.
Accelerator: strengthen TODO to FIXME
Use PlatformUtils methods where applicable
Merge pull request #88 from scijava/urltofile-windows

Fix FileUtils#urlToFile() on Windows
ModuleService#getSingleInput: skip unfillable inputs

If an input is unfillable (i.e., the ModuleItem's isAutoFill method
returns false), then it is intended that preprocessors not fill in the
input with any sort of preset or "active" data value.

For example, the ActiveDisplayPreprocessor should not fill in a Display
input with the active display if that input is marked autoFill=false.

This fixes a longstanding bug with the Active*Preprocessor classes,
which made it impossible to exclude inputs from being handled by them.

Fixes http://trac.imagej.net/ticket/2022.
Add a unit test to verify the getSingleInput fix

The test passes, but fails if the previous commit is reverted.
Merge branch 'skip-unfillable-inputs'

This branches fixes a longstanding bug in the autofilling preprocessor
logic, which would erroneously autofill inputs marked autoFill=false.
Bump to next development cycle

Signed-off-by: Jenkins <jenkins@dev.loci.wisc.edu>
ClassUtils: move deprecated methods to the bottom
Add utility class with generic type methods

This class recapitulates some of the functions from ConversionUtils
and ClassUtiles, as well as adding new functionality. The previous
methods will be deprecated in favor of those in this class.
Deprecate methods now available in GenericUtils
ClassUtils: tweak javadoc style
ClassUtils: refactor setValue method
ClassUtils#setValue: use more exact field type

Rather than calling field.getGenericType(), let's use the superior
GenericUtils.getFieldType method to get the more exact generic type.
Update unit tests for GenericUtils

This converts the tests of now-deprecated methods from ClassUtils and
ConversionUtils to test the analogous GenericUtils methods instead.
Merge branch 'generic-utils'

This branch reorganizes the lower-level generics-related helper methods
of ClassUtils and ConversionUtils into a dedicated utility class:
GenericUtils. The old method signatures have been deprecated.

The original idea was to use some of these methods to assist with better
ObjectIndex lazy object resolution, but it turns out that even with
clever use of generics reflection, it is not tenable to reliably detect
the type from the LazyObjects instance alone. So the new features of
GenericUtils, while very nifty and probably useful in the future, are
not in immediate use anywhere within SciJava Common.
TestUtils: valid calling code locations do not include .jar files

The whole point of the getCallingCodeLocation() method in the TestUtils
class is to be able to determine a unique location for a directory
inside the target/ directory of the current Maven project.

Therefore, code locations in .jar files are not appropriate: there is
no associated target/ directory.

Thanks, Jaspar Jenkins, for running the regression tests so faithfully
and pointing out that the imagej-plugins-uploader-{ssh,webdav} projects
require this change to run their integration tests properly.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Merge pull request #92 from scijava/test-utils

TestUtils: valid calling code locations do not include .jar files