add unified interface for accessing file system

**please review**
> Especially since you can simply choose to pass dummy values to the directories you don't want to use, if you really want to. 

This is very, very ugly because it is not if I want to, I have to, there is no way around it.

> @cos as you can see the reason why you need to construct a FileUtil for this class is it needs access to the directory associated with the compiled definition. In order to be able to make this dependency more granular, it would be necessary to construct four separate FileUtil classes which each do very similar things with different directories.

I'm starting to think the problem is Guice. If you're thinking about the easiest way to please Guice, yes, you need extra classes to annotate a simple value. One could argue we want to this for better type safety. Ok, but then we should embrace it, create the extra classes, not pass around the `FileUtil` intersection type.

>  If you can provide me with an alternate solution which is cleaner than this one, or provide me a compelling argument why the solution 

The problem here is that anybody who has something to do with the kompilation directory will now have to know about all the stuff in FileUtil -- `FileUtil.kompiledDir` is private. The solution:

The JavaSymbolicBackend doesn't know about `FileUtil`, it only receives what it needs, i.e., kompiledDir.
```
JavaSymbolicBackend(
             Stopwatch sw,
             Context context,
             BinaryLoader loader,
             Provider<RuleIndex> index,
             Provider<KILtoBackendJavaKILTransformer> transformer,
             File kompiledDir) {
```

`loader.saveOrDie(files.resolveKompiled(JavaSymbolicBackend.DEFINITION_FILENAME),`

is replaced with

`loader.saveOrDie(new File(kompiledDir, JavaSymbolicBackend.DEFINITION_FILENAME),`