shared thumbnails: reconsider handling of absent MTime (and file name?) in metadata

The current thumbnail spec guidance on the Thumb::MTime datum inside the thumbnail metadata is that the file is practically invalid in its absence. That requires strict coordination of timestamps across systems, which some data distribution mechanisms (eg. git, and git-annex based on it) heavily disagere with.

Given that shared thumbnails already need to be managed by an application outside the regular thumbnail generation regime, I suggest that at least for shared thumbnails (but probably best for all, for consistency), a missing Thumb::MTime be allowed and interpreted as a statement of "Trust me, this is current; I'm managing this thumbnail".

The requirement that that datum must be in there has been around long enough that no thumbnail generators should be around any more that don't set Thumb::MTime, and users that don't understand the new semantics implement the sane fallback of thumbnailing again.

The problem I see with this suggestion is that "Trust me I'm current" thumbnails might not only have no Thumb::MTime set, but also disagree in their stat'd mtimes, and that applications might discard the thumb based on that already without looking into it. A sentinel mtime for those files would be an option, but I'm confident there are more.

[edit: sorry, prematurely submitted]