Remove any claim of avoiding traversal attack via backup recovery

This code is problematic for legitimate use cases where the user has
set up symlinks of things like tablespaces after resolving the
symlink.

Unfortunately, this code was put in place in attempt to make sound a
previously unsound prior approach (looking for traversals in the
member name, e.g. ".."), as a malicious tar archive could contain both
a symlink and then a non-relative member name to mount a traversal
attack anyway.

And previous to that, in WAL-E v0.6, no attempt to avoid this attack
was done at all, via reliance on tarfile's "extractall" method.  So,
regressing v0.7 (now in alpha) back to the previous state of affairs
is no disaster.

Putting aside the idea of malicious archives, part of this is also
mundane program-"oops" safeguarding, so it'd be nice to get some level
of safety back somehow.
Fix systemic spelling error in source

"restor_spec" is now "restore_spec".
Avoid attempting to open and fsync extracted symlinks

This does not work.  Tar files that have symlinks pointing at a
non-existent file should not cause WAL-E to crash.  And, it doesn't
see possible to open a symlink on most platforms, and particularly on
Linux, and without an open() there can be no fsync().  A moment's
research was expended on the matter, but at this time there is no
known portable way to flush the *contents* of the symbolic link's
text.

The reasons to allow such dead-end symlinks in tarfiles is obscure.
Part of this is backwards compatibility with old archives that allowed
them, presuming they'd later be overwritten by the user, interpreted
within a chroot, or reference a file elsewhere within the same data
directory that is yet to be extracted by another volume being
downloaded.
Use s3-external-1 endpoint for us-standard

This is the endpoint in us-east-1, where most instances are.  This is
not being applied to the v0.6 maintenance releases to avoid changing
behavior for those who are closer to Seattle.
Elide other backends besides S3 in requirements.txt

It's not clear how to make things cleanly optional but not a usability
nightmare (e.g. installing *no* backends by default for 'pip install'
based people) within the Python packaging framework, so don't try..for
now.