ETag is based on the file's mtime. #performance

Quoting the documentation of the `DAV\IFile::getETag` method:

> An ETag is a unique identifier representing the current version of the file. If the file changes, the ETag MUST change.

In [`DAV\FSExt\File`](https://github.com/fruux/sabre-dav/blob/93e61954fd82dfc397055cec5a10a636cf982a45/lib/DAV/FSExt/File.php#L115), we use the [`md5_file` function (documentation)](http://php.net/md5_file). I was thinking: I wonder if it can cause performance issue? I think yes because the [`md5_file` function (implementation)](http://lxr.php.net/xref/PHP_5_6/ext/hash/hash_md.c#135) reads the entire file in order to compute the MD5 hash. So with a file of 5Gb, it can hurt. I was then thinking: why not having a better way to compute the Etag of a file? Well, the [`mtime`](http://php.net/filemtime)! In order to protect the data behind the Etag, we encode this data with a SHA1.

However, I have also noticed that `FS\File` returns a `null` Etag while we can apply the same approach. So this PR fixes these two guys + respective tests.

Finally, a last patch ensures that the `fstat`'s cache is clear before computing the `ETag`. We optimize this cache invalidation by clearing only the cache of the current file, not for all the FS.
I understand, no worry :-).
You said:
> In case we clear the statcache, we have to pay a performance penalty for it.

Where do you see a penalty?