Allow the kernel to cache inode attributes

[jacobsa]

The performance of statting is not super great, as shown by the benchmark added in 8f8d260. Since remote updates to GCS result in a new object generation (aside from the metadata issue covered by #114) and a new generation causes a new inode number, it should be safe to tell the kernel to cache inode attributes. Do that and see how it affects performance.

[jacobsa]

(I don't think #114 needs to be a blocker for this one. We already cache stat results for a particular generation forever internally, in the form of the inode storing a copy of the gcs.Object record.)

[jacobsa]

Also check the effect on write performance benchmarks with small writes. Right now, it looks like the kernel has to send getattr requests for every tiny write.

[jacobsa]

Oops, there is one subtlety here: while nothing about the GCS object can change, it can be deleted, in which case stat::st_nlink changes. So we probably want to use the setting of --stat-cache-ttl as the TTL, instead of allowing the kernel to cache forever. Users who care about st_nlink being up to date will need to turn it off, as before.

[jacobsa]

Almost done, at e621b72. I was wrong about small write performance being helped; that will probably require writeback caching (#113) to be finished, too. But stat performance gets way better.