Instead of removing the FileEntry 'just' invalidate its cache.

When there is an error introduced by #include-ing a file we should be able to
hit the disk (in cling's context) the next time. The user could fix it in the
meanwhile.

Newer clang supports a flag which can be used to mark the user files as volatile.
This means that the file stat will be invalidated, causing clang to hit the
disk and fetch the new content of the FileEntry.

The complication comes from the fact that when the file size of the file entry
is invalidated the cache in the SourceManager is not syncronized, thus clang
issued an error. The patch in clang checks if the file size == 0 and the
modification time == 0 this means that we are in cling's context and have to sync
the cache and continue with no errors.

This fixes an issue exposed by Jerome's implementation. Before we removed the
entire FileEntry to achieve the same behavior, however the SourceManager kept
the reference to it. This leads to seg faults when iterating over the included
files (eg. .files or .storeState)
Move the implementation in an interpreter-independent object.

We don't need the intepreter to store clang's state. We can use a separate object
for that which allows to be reused.

Provide *much* shorter and cleaner implementation.
No need of cleanup in the testsuite - we use temporary uniquely named files.
Remove commented out code.
Publish the useful helper class.
Update references to the file.
We don't need to keep track of the .L-ed files.
The implementation of TCling is very raw and I bet we can improve it a lot.
Now the libraries and the #included files are not in the same place.
Reset the cache only if there is a fileentry associated with it.

This avoids removing the cache of the virual file, wrapping the memory buffers
in cling.