add unified interface for accessing file system

**please review**
Cosmin, the problem with this approach is I'd like to reach a point where FileUtil or classes like it are the only objects constructing File instances. I definitely can do what you describe, but it provides a less nice API to the user who wants to read and write to files. We end up back in the situation we started with where very little is stopping the user from unknowingly breaking the paradigm by constructing their paths manually.

I know you hate Guice, but it has nothing to do with this. I could very easily do as you describe and construct the API so that each call site calls the File constructor. Nothing having anything to do with Guice constrains me here one way or the other. The question is whether I want to expose an API to our developers which encourages the raw manipulation of File objects. I decided I wanted to discourage that in order to keep the code from fragmenting (which as you can see it had done in the past over time). That means having strongly typed methods like "resolve path in temp dir" and "copy file to kompiled directory". This is literally the nicest API I could come up with for accomplising that goal. I really don't think it's that big of a loss to have to spend a little more effort to construct this object outside production code, especially because I'm pretty sure that's something you should not be doing anyway. Test code should be mocking dependencies like this which have side effects on the file system. And production code should instantiate this class via the injector, making this not an issue.

I'm going to give you a chance to respond again to this to note your objections, but then I'm going to merge this. It's good to express your opinions, but it's also good to accept that sometimes the project decides to go in a different direction than you see as ideal yourself.