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.
This example excatly illustrates what I mean.

In case we clear the statcache, we have to pay a performance penalty for it. Therefore we try to let the statcache be handled by php itself.
When you put this functions into separate files and exec them one-by-one the result will always be correct (because accross php requests php makes sure the cache is up2date).

So my question again: will this kind of operations (read, write, read again) happen within one request in sabre-dav? If not we don't need to clear the cache.