fix out-of-order 'revno' assignment for commits with same timestamp

In src, revision numbers are intended to be simple, consecutive integers in commit date order. When multiple commits share the same date, src breaks the tie by using the native commit ID. Unfortunately, this tie-breaking is based upon lexicographical comparison, thus can give incorrect results. For instance, with native ID's (1.1, 1.2, ..., 1.10, 1.11), lexicographical ordering sorts them as (1.1, 1.10, 1.11, 1.2, ...), with 'revno' assignment giving (__r1__=1.1, __r2__=1.10, __r3__=1.11, __r4__=1.2, ...). RevisionMixin.pred() and succ() work by walking native revision ID's, so topology is unaffected, but revno presentation and specification is, adversely so. For instance:

% src list sample.txt
= sample.txt ==========
3  * <date> eleventh
2  - <date> tenth
11 - <date> ninth
10 - <date> eighth
9  - <date> seventh
8  - <date> sixth
7  - <date> fifth
6  - <date> fourth
5  - <date> third
4  - <date> second
1  - <date> first

This sort of situation can arise easily when src fast-import imports a history from Git which has undergone interactive rebasing, which can set the committer timestamp of many commits to the same value. For example, given git rebase -i HEAD~50, after commit HEAD~50 is edited, the committer timestamp of the remaining 49 commits will likely have the same value when replayed atop HEAD~50.

Fix by sorting native ID's with natural ordering rather than lexicographical.