Versioning: allow a number as replacement for date in shapshot information
    
    This provides a shorter and simpler method for constructing the
    shapshot information field. Sort order is obviously preserved, but
    a simple number has the following minor advantages:
    - it is shorter, which matters with the already fairly long git
      snapshot fields
    - the maintainer does not have to look up the commit date
    
    The main motivation is that for some projects, the date of the commit
    is not interesting. For example, systemd project makes systemd-stable
    branches with commits which are cherry-picked from the main development
    branch, or from newer stable branches. But the order in which commits
    are cherry-picked is not stable: when a commit is an obvious and important
    bugfix, it may be cherry-picked onto multiple stable branches at once.
    But sometimes we only belatedly realize that something is a fix, or
    poeple request something to be backported, and then one or more patches
    are applied. Git associates two dates with a commit: the author timestamp
    and the application timestamp. For backported commits, the author timestamp
    can jump backwards and forwards and is not interesting. The commit
    timestamp should mostly be monotonic, but it's just not interesting
    for backported commits, because it shows when the stable branch maintainer
    had time to do backports. The commit date is not harmful, but it
    doesn't bring enough value to make it required in the snapshot
    information field.
    
    A final minor technical motivation is that both the author and commit
    timestamps in git are controlled by the committer and may not be monotonic.
    If upstream has unreliable commit timestamps, using a number is better
    and simpler than making up some different dates downstream.
    
    This implements my suggestion from
    https://pagure.io/packaging-committee/pull-request/908#comment-90159.