Revert compatibility break with NodePath and ConfigurationTransformation

[lucko]

Reverts some breakages introduced in #92

[dualspiral]

@NonNull ConfigurationTransformation.NodePath

[lucko]

Not valid:

The only other way to do it is to add an import statement for

import ninja.leaping.configurate.transformation.ConfigurationTransformation.NodePath

and then have

Object[] visitPath(@NonNull NodePath inputPath, @NonNull ConfigurationNode valueAtPath);

but I thought that was unclear, as an interface with the same name already exists in the same package.

[dualspiral]

That's not valid? Huh... Java surprises me every day.

[dualspiral]

To comment: the signature of this method will still have changed slightly (it was SimpleConfigurationTransformation.NodePath), but it actually points to the same class as NodePath's outer class is ConfigurationTransformation, which is the superclass of SimpleConfigurationTransformation. The nuance was likely what caused the confusion with it not being accessible in the previous version - it looked inaccessible from the code that was written, but it actually wasn't.

I checked the bytecode from Nucleus which was compiled using configurate 3.2, it references ConfigurationTransformation.NodePath not SimpleConfigurationTransformation.NodePath - so this change should be fine.

[kashike]

ConfigurationTransformation.@NonNull NodePath

[dualspiral]

Any stylistic comments aside, I think this looks fine, given the comment I gave before.

@kashike It's probably in our interest to get this wrapped up and pushed out of the door sooner rather than later. I'll let you pull the lever if you're happy with this, as I said in my comment, the bytecode in Nucleus references
ninja.leaping.configurate.transformation.ConfigurationTransformation$NodePath, so this should be OK and not an API break.