Replace native file ops with delegated calls

[dansanduleac]

Seeing how you have this nice branch of Ivy already set up, I decided to go to you guys with this first.
Basically, I'd really love to be able to test my entire workflow, including the use of Ivy to publish things, and I'd like to do this safely.
Now, since I'm using Java 7, there's a really nice tool called memoryfilesystem which provides a Java 7 NIO FileSystem stored entirely in memory.
I can (and did) extend File to make all operations use a nio Path behind the scenes, but the blockers are all these new File() calls, as well as new FileInputStream etc. So I've decided to make all these into function calls, all centralised under Ivy's FileUtil, that can easily be overridden. (and of course, still compatible with Java 5).

Hence I've translated:

• new File(...) into FileUtil.newFile(...)
• new FileInputStream(...) into FileUtil.newInputStream(...) -- returns an InputStream, not a FileInputStream but haven't had problems with this fact anywhere in the code
• new FileOutputStream(...) into FileUtil.newOutputStream(...) -- returns an OutputStream - same argument as above
• new FileReader(...) into FileUtil.newReader(...) -- returns a Reader not a FileReader but again, same argument as above

You'd overwrite the default behaviour by saying:

// PathBackedFile is expected to provide the same constructors as java.io.File with the exception of the constructor taking a FileDescriptor
FileUtil.setFIleImpl( PathBackedFile.class ); // where PathBackedFile <: File
// Set FileOps, which dictate how to create Input|Output Streams and Readers given a File
FileUtil.setFileOps( new FileUtil.FileOps {
  public InputStream newInputStream(File f) { 
    if (f instanceof PathBackedFile)
      // PathBackedFile.path is a java.nio.file.Path
      return java.nio.file.Files.getInputStream( ((PathBackedFile) f).path );
    else
      return super.newInputStream(f);
  }

  // etc for newOutputStream and newReader
});

Edit: There's also RandomAccessFile that I should fix, possibly in the same way: allowing the user to provide their own implementation. Currently it's only used in org.apache.ivy.plugins.lock.FileBasedLockStrategy.