Invert priorities

Making "high" priorities low numbers was a mistake.

1. Things that come freshly to attention are much more often among the
   highest priority things and are very rarely lower priority that
   everything else being tracked.

2. Logging the completion of an already-done task, a task that was *so*
   high-priority that it was completed before even being tracked here,
   feels bad when it ends up initially marked as lowest-priority-ever
   unless some additional action is taken.

3. Marking a new task highest-ever-priority is fairly common and
   oughtn't cost two log entries.

4. All the high priority tasks ever tracked oughtn't be fighting over
   the smallest-representable IEEE floating point values, as they all
   try to get slightly closer to zero. When highest-priority is now(),
   these tasks get nicely spread out over the keyspace.  This helps with

   * keeping priority values integer-rounded, which helps with
     * serialized log size
     * log parsing simplicity (clients needn't support scientific notation)
     * preventing underflow

  * making the priority-sorted 'done' views be not-completely-useless
    as all the tasks that have ever been high-priority get haphazardly
    interleaved near zero.  Instead, it becomes almost chronological.

This change does rather a lot of violence to current users of this tool,
inverting their displayed task list order & making no provision
whatsoever for gentle migration across this change of an implementation
detail.  This is fine, because there's still only one user of this tool:
the author.  Breaking changes like this will not be tolerated after
deployment.