No longer pin setuptools as modern Pants supports modern setuptools (#38

)

### Problem
We originally had to manually pin setuptools to 5.4.1 to workaround pantsbuild/pants#3948.

This is no longer the case thanks to multiple changes to Pex and Pants, most recently seen at pantsbuild/pants#6594.

Continuing to pin to 5.4.1 prevents Python 3 from working, as seen with https://travis-ci.org/pantsbuild/setup/jobs/507117401#L553.

### Solution
Remove all custom code resolving setuptools and let Pip install and resolve as it normally does.

1. 14 fewer lines of custom code, making the script easier for people to understand and for us to develop.
    * Note `pip` ships with `setuptools` by default for a reason. It's a sensible default.
1. We end up with the same version as Pants after all is done, which is the behavior we want.
1. If we ever needed to bump the pinned version, we would need people to curl the script again, which is very infrequent for them to do.

### Result
Because we pin `setuptools` in Pants' `requirements.txt`, we end up getting the exact same setuptools that Pants is using for that version.

This is the output after creating a new virtual env:
```
Successfully installed Markdown-2.1.1 Pygments-2.3.1 ansicolors-1.0.2 asn1crypto-0.24.0 asttokens-1.1.13 certifi-2019.3.9 cffi-1.11.1 chardet-3.0.4 configparser-3.5.0 contextlib2-0.5.5 cryptography-2.6.1 docutils-0.12 enum34-1.1.6 fasteners-0.14.1 faulthandler-2.6 future-0.17.1 idna-2.8 ipaddress-1.0.22 monotonic-1.5 packaging-16.8 pantsbuild.pants-1.15.0.dev4 pathspec-0.5.9 pex-1.5.3 ply-3.11 psutil-5.4.8 py-zipkin-0.17.0 pycparser-2.19 pyopenssl-17.3.0 pyparsing-2.3.1 pystache-0.5.3 pywatchman-1.4.1 requests-2.21.0 scandir-1.2 setproctitle-1.1.10 setuptools-40.4.3 six-1.12.0 subprocess32-3.2.7 thriftpy2-0.4.2 twitter.common.collections-0.3.10 twitter.common.confluence-0.3.10 twitter.common.dirutil-0.3.10 twitter.common.lang-0.3.10 twitter.common.log-0.3.10 twitter.common.options-0.3.10 urllib3-1.24.1 wheel-0.31.1 www-authenticate-0.9.2

New virtual environment successfully created at /Users/eric/.cache/pants/setup/bootstrap-Darwin-x86_64/1.15.0.dev4_py27.
```

pants

@@ -20,16 +20,6 @@ PANTS_BOOTSTRAP="${PANTS_HOME}/bootstrap-$(uname -s)-$(uname -m)"
 
 VENV_VERSION=${VENV_VERSION:-16.0.0}
 
-# This requirement is installed before pantsbuild.pants to hack around
-# interpreters that have newer setuptools already installed, effectively
-# re-installing an older setuptools and pinning low to a version known to be 
-# ingestable by both pants and pex for all reasonable versions of pants.
-# See:
-#   https://github.com/pantsbuild/pants/issues/3948
-#   https://github.com/pantsbuild/setup/issues/14
-#   https://github.com/pantsbuild/setup/issues/19
-SETUPTOOLS_REQUIREMENT="setuptools==5.4.1"
-
 VENV_PACKAGE=virtualenv-${VENV_VERSION}
 VENV_TARBALL=${VENV_PACKAGE}.tar.gz
 
@@ -111,14 +101,10 @@ function bootstrap_pants {
 
   if [[ ! -d "${PANTS_BOOTSTRAP}/${target_folder_name}" ]]; then
     (
-      # NB: We setup the virtualenv with no setuptools to ensure our
-      # ${SETUPTOOLS_REQUIREMENT} wins.
       venv_path="$(bootstrap_venv)"
       staging_dir=$(tempdir "${PANTS_BOOTSTRAP}")
-      "${python}" "${venv_path}/virtualenv.py" --no-setuptools --no-download \
-        "${staging_dir}/install"
+      "${python}" "${venv_path}/virtualenv.py" --no-download "${staging_dir}/install"
       "${staging_dir}/install/bin/pip" install -U pip
-      "${staging_dir}/install/bin/pip" install "${SETUPTOOLS_REQUIREMENT}"
       "${staging_dir}/install/bin/pip" install "${pants_requirement}"
       ln -s "${staging_dir}/install" "${staging_dir}/${target_folder_name}"
       mv "${staging_dir}/${target_folder_name}" "${PANTS_BOOTSTRAP}/${target_folder_name}"