Move file system traversal code into the tar partitioner

Besides making more sense than being coupled to an s3 operator, the
impetus is to help find out where memory is being expended during this
phase of wal-e's operation on systems with many files.  On some
systems it can easily be over a gigabyte, and with overcommit off this
can make it extraordinarily difficult to take backups (because of
fork-exec, wherein the fork must commit all that memory).

On the same system, though, a byte-count of the output of 'find' is
only about 50-100 meg, so there's clearly a times-ten blowup
somewhere, and the guess is it has to do with the eagerly tarfile
data-structures.  This breaking out of operators will hopefully help
with finding out.
Add __slots__ to StreamPadFileObj

Comment from the source:

Try to save space via __slots__ optimization: many of these can be
created on systems with many small files that are packed into a tar
partition, and memory blows up when instantiating the tarfile instance
full of these.
Incrementalize the generation of tar partitions

Now instead of happening up front, the segmentation occurs lazily.
This is because holding so many TarInfo values can have an enormous
memory footprint.