Use Path instead of java.util.File in API signatures

Several of our interfaces that are about to be released under taverna-osgi and taverna-engine had methods with java.io.File in their signatures - however I don't think there should be any reason why this should not be the more modern java.nio.file.Path

It's easy to move between File and Path as there's file.toPath() and path.toFile() methods that work well with local file:/// paths.

I had a quick search-replace across the interface signatures inside *api of taverna-osgi and taverna-engine, but didn't change the implementations beyond doing .toFile() on the incoming Path's - so the implementations don't currently support non-file:// Paths (e.g. would not support Paths from inside an robundle).

(When changing from File to Path in implementation, be aware that Path have more explicit exceptions, while File could silently fail - e.g. file.mkdir() would just return no matter if it worked or not)

Although changing to use Path everywhere probably is good for stability (explicitly handling exceptions where needed), that is a bigger job, so
I think at least changing the API interface signatures now means we would be allowed to later change the implementations without affecting the callers.

I have updated the commandline to the modified calls - but not the workbench (which has other compile issues).