Add Libproxy support

Currently proxy configuration is limited to manual proxy server types and requests does not support wpad/pac proxy server. Make use of libproxy which takes care of it and also respects desktop/system configurations.

Hi @janbrummer, Requests isn't accepting new features at this time. It looks like what you're trying to accomplish should be relatively straight forward through the existing `proxies` interface though. We'll leave these kinds of decisions to user code who may need special workflows.

May i ask you why there is a feature freeze right now?

You are right that it is also possible to do this using the existing interface. The problem just is that we need to do it for every python application using requests instead of doing it once. 

> May i ask you why there is a feature freeze right now?

Because we feel the library is feature complete and there is no reason to add additional feature surface area. It's been in feature freeze successfully for years at this point

So you are feature complete but are missing a mandatory proxy feature in a business environment. Doesn't sound solid. Can you please reconsider it, because this is a major problem in this environment because we would need to support this downstream patch forever in each distro.

There are an innumerable number of mandatory business requirements across different companies.

If this is easily solved through the existing interfaces, it's not the responsibility of upstream libraries to take on the technical burdens of companies. Especially if it negatively impacts the common use case.

Even if we were accepting new features, I don't think this would pass the bar for acceptance.

Maybe i wasn't clear enough: Libproxy features much more than just handling pac servers. It is capable of extracting the right proxy configuration on OSX, Windows and Linux (GNOME/KDE/Sysconfig/...) so that a user just can start a python application using requests and its working (because it has been configured in system). No need to find out that there is a proxy configuration necessary and how to configure it (most application do not offer this configuration option).  Beside the feature freeze what's else would be blocking the merge of libproxy? Am i'm missing something else?

The notable issues:

* PyGObject requires a C compiler. We don't accept non-native Python dependencies.
* We don't accept LGPL dependencies, this has been a significant amount of pain with Apache in the past (#5797)
* This is almost certainly a breaking change on misconfigured/unexpectedly configured systems.

- I can write a non PyGObject version which adds the dependency but it will of course still make use of the c library. In a previous bug report regarding libproxy there was the decision that it is okay but it should also be possible to add a binary wheel.
- In this case the license can be adjusted to MIT or whatever you prefer.
- -For the last one. It's not as libproxy prefers environment variables and thus does not break the existing behaviour.



> In a previous bug report regarding libproxy there was the decision that it is okay but it should also be possible to add a binary wheel.

That may be ok for other libraries but it isn't ok for this project. Requests will not be taking any non-native Python dependencies, regardless of pre-compiled wheel availability.

> It's not as libproxy prefers environment variables and thus does not break the existing behaviour.

I think you're assuming everyone is using a proxy. Most users are not and do not have any environment configuration defined. However, if there is something available at the system level that they do not want enabled, this will now be detected and potentially break requests.

We could go back and forth on these things, but the outcome will almost certainly remain what we started with. Thanks for the contribution but we're not inclined to accept this functionality at this time.