Treat stat fields correctly as signed, unsigned, or unspecified (cf. POSIX).

Treat stat fields correctly as signed, unsigned, or unspecified (cf. POSIX).

Patrick reported a problem with restore on Cygwin that was being
caused by bup's handling of unknown uid/gid values; it turns out that
Cygwin returns -1 in that situation:

  http://www.cygwin.com/cygwin-ug-net/ntsec.html
  "Special values of user and group ids"

However, bup didn't see -1; bup saw 4294967295, because it was
incorrectly converting some stat field values as unsigned when POSIX
says that they should be signed (or doesn't specify):

  http://pubs.opengroup.org/onlinepubs/009695299/basedefs/sys/types.h.html

To fix the problem, convert the stat fields correctly -- using the
widest type available (PY_LONG_LONG), and add a new common metadata
record (_rec_tag_common_v2) to store them correctly.  Test at runtime
for potential overflows that we can't rule out at compile time.

Store all of the fields (excepting the timestamp ns values, which we
already force to be non-negative) as signed vints because the overhead
should be negligible, and doing so means that we won't have to break
backward compatibility again if we ever decide we actually want to
store negative values.

Continue to read the legacy format as before, with the realization
that this may leave some existing archives broken.  At the moment, the
only known case is the Cygwin "unknown uid/gid" problem cited above,
and to help with that and similar cases, we'll be adding
--map-{user,group,uid,gid} options to restore.

Thanks to Patrick Rouleau <prouleau72@gmail.com> for the initial
report leading to the deeper problem.

Signed-off-by: Rob Browning <rlb@defaultvalue.org>
Reviewed-by: Gabriel Filion <gabster@lelutin.ca>