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.

Why would you even want this?

> 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. 

So `new File(kompiledDir, foo)` is uglier then `files.resolveKompiled(foo)`? If you don't like it, you could even provide some helper methods/classes. But don't make them into a monolithic dependency that needs to be passed around everywhere.

> 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.

`kompiledDir/mystuff` is not rocket science. What I'm reading here is that if we entangle this enough, and make it hard enough for the developer, he won't make mistakes anymore. It might be true, because he won't develop anything new -- he will spend his time writing mocking code for all the dependencies. 

Another way to put this, if you want a more engineerish explanation, is that your approach increases the coupling of the system. And with very little gain. 

> I know you hate Guice

You know wrong. I don't hate Guice. I see Guice as a nice thick rug. It can be comfortable, and thus useful. But, being thick, you can also shove a lot of dirt under it. The dirt is the high coupling.

> 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.

Thank you for the opportunity to object without effect! I've been doing this quite a bit lately.