Don't produce archives with mismatched file sizes

Case 90421: Because of the way tar files are constructed, and
the way Archive::Tar::Builder buffers its data, there is a race
condition that makes it possible to have written a header for a
file to disk and later find out that the file size listed in
the header is no longer correct, either because someone has
appended to the file or because someone has truncated the file.

Previously, the b_builder and b_file code did a poor job of
handling this condition (because they were unaware of it) and
ended up producing corrupt archives which could not be extracted.

This commit addresses both the append and the truncate problem,
but in two different ways. For example:

    * If a file's header was written to indicate that the file was
      N bytes long, and it is later found to be N + 1,000 bytes
      long, only the first N bytes are used, even though more were
      available. (The previous behavior was to silently produce a
      corrupt archive.)

    * If a file's header was written to indicate that the file was
      N bytes long, and it is later found to be N - 1,000 bytes
      long, Archive::Tar::Builder will error out immediately,
      making it obvious that there is a problem. (The previous
      behavior was to silently produce a corrupt archive.)

Unit tests have also been added to verify the handling of this race
condition.