Co-authored-by: Jan-Michael Brummer <jan-michael.brummer1@volkswagen.de>

Co-authored-by: Jan-Michael Brummer <jan-michael.brummer1@volkswagen.de>

If the library version is not specified, meson installs the shared
object using only the soversion, and this causes ldconfig to emit a
warning that the shared object is not a symlink. Specifying a version
that matches the project version means that version is used for the
shared object, and the soversion-named file is then a symilnk to that,
which is common across other libraries, and avoids the warning from
ldconfig.

https://bugzilla.redhat.com/show_bug.cgi?id=2247508

- Handle proxy URLs being provided with a scheme
- Don't assume that target URL scheme == proxy scheme
- Use proxy provided without a scheme specifier for all target URL
  schemes
- Free memory allocated for hash table keys and values

It is only used there, and the project root is added to the list of
include directories last. This means that a config.h may inadvertedly be
included from a completely different place when building libproxy as a
subproject. The backend directory, where the generated
px-backend-config.h ends up is the first include path in the list.

This commit removes config.h entirely, as the only other thing in it,
the generated PACKAGE_VERSION define, is not used anywhere

Fixes: #260

Co-authored-by: Jan-Michael Brummer <jan-michael.brummer1@volkswagen.de>

Windows proxy servers can be set either with or without a scheme where without
implies http, and with or without a port where without implies the
default port for the scheme.

Unfortunately, g_uri_parse_scheme("proxy.example.com:3128") returns
"proxy.example.com" rather than NULL (while
g_uri_parse_scheme("1.2.3.4:3128") returns NULL), meaning that such
proxy configurations did not get http:// prepended to them, causing
e.g. GProxy to reject them.

With this change we simply search for the presence of :// in the URI
instead. While a URI technically doesn't have to contain // after
the scheme separator, such URIs should not occur in this context

When discovering a PAC URL through WPAD, libproxy would download the
file, but never call set_pac() on the PAC Runner interface, unlike in
the case with an explicitly configured PAC URL. This would cause the
PAC Runner implementation to just return an empty string from run()

Co-authored-by: Jan-Michael Brummer <jan-michael.brummer1@volkswagen.de>