[v3.4.x] Fix installation under Python 3.5, don't use strict requests version pinning to avoid issues with conflicting dependency version requirements

[Kami]

v3.4.0 release introduced a setup.py metadata regression which brakes installation under Python 3.5 when using pip.

Since that release should still support Python 3.5 we need to fix the issue and release v3.4.1 bug fix release.

This pull request fixes the setup.py metadata issue. Sadly none of the existing install checks caught the issue (and it's basically impossible for them to catch it - to catch the issue we would need to build sdist file under Python >= 3.6 and then install it under Python 3.5).

[Kami]

I tested and confirmed the fix using the following approach:

# Create distribution under Python 3.py
python setup.py dist
# Create Python 3.5 venv and try to install previously created dist
rm -rf py35-test/ ; python3.5 -m venv py35-test ; source py35-test/bin/activate
pip install dist-v340/apache-libcloud-3.4.0.tar.gz

To be double sure it indeed fixes the issue, I will also upload it to test PyPi server and test installing it from there using Python 3.5.

[Kami]

Tested it with Test PyPi server and it seems to be picking up and trying to install correct version of requests library now (but installation fails since that version is not available on test PyPi server.

$ python3.5 -m pip install --index-url https://test.pypi.org/simple/ apache-libcloud
Requirement already satisfied: apache-libcloud in /home/kami/w/libcloud/libcloud
Collecting requests>=2.25.1 (from apache-libcloud)
  Could not find a version that satisfies the requirement requests>=2.25.1 (from apache-libcloud) (from versions: 2.5.4.1)
No matching distribution found for requests>=2.25.1 (from apache-libcloud)

Previously it would incorrectly try to use >= 2.26.0 which won't work under Python 3.5

[Kami]

Technically, since Libcloud is a library and not an application it may actually be the best to simply unpin requests.

I know that is not ideal because of #1594, but it's probably the safest since this >= 2.26.0 actually has potential to brake more user installations in case they already require conflicting version of requests.

So for now I will actually do just that, so we don't need to do another bug fix release in the near future when more people start reporting it's causing issues in their environment due to the conflicting dependency version.