Add --skip-existing flag to upload command

[sigmavirus24]

This new flag allows users to force twine to skip existing files when
uploading to PyPI. For example:

~/s/gh3.py git:develop ❯❯❯ twine upload --skip-existing dist/*
Uploading distributions to https://pypi.python.org/pypi
Uploading github3.py-1.0.0a2-py2.py3-none-any.whl
  Skipping github3.py-1.0.0a2-py2.py3-none-any.whl because it
appears to already exist
Uploading github3.py-1.0.0a2.tar.gz
  Skipping github3.py-1.0.0a2.tar.gz because it appears to
already exist

Closes #115

[sigmavirus24]

@nedbat Would you mind reviewing this as well?

[nedbat]

Is 400 only sent because the file already exists? isn't there some more certain way to know what happened?

[sigmavirus24]

Not quite. I don't think trying to match strings in the body of the message will be wise. The status code is consistently 400 in my testing.

[nedbat]

But 400 means Bad Request, which could happen for all sorts of reasons, and who knows what might come in the future that would produce 400. I'm not saying "file exists" could produce other status codes, just that sometimes 400 might mean something other than "file exists".

[sigmavirus24]

I don't disagree. It looks like the reason part of the status line returns something like:

(Pdb) p resp.reason
'A file named "requests_toolbelt-0.4.0-py2.py3-none-any.whl" already exists for  requests-toolbelt-0.4.0. To fix problems with that file you should create a new release.'

Again this seems kind of fragile, but may as well test for it. (To be clear, the behaviour of PyPI in this matter can change very drastically in the coming months given the timeline for Warehouse's release.)

[nedbat]

How about a compromise: keep this check, but include resp.reason in the message?

[sigmavirus24]

After refactoring much of the upload module last night, this becomes:

A) Much easier to test
B) Simpler to pull that logic out into its own function so we can test just that.