For some reason apache silently fails now if a relative path is passed.

To make SSL tests fail with our testing certificate we create and empty
GTlsDatabase passing /dev/null to g_tls_file_database_new(). This no
longer works with newer glib-networking, since an empty file is
considered an error by gnutls and
g_tls_file_database_gnutls_populate_trust_list() now handles gnutls
errors properly. Instead, we can just use the system CA file that won't
contain our testing certificate for sure.

Fixes #201

See GLib commit f0a7b147806e852e2090eeda6e4e38f7d3f52b52 for full
details, but now the extra RESOLVING event is not emitted any more.

To cater for situations where libsoup is run against an older version of
GLib, keep a runtime check for older versions.

Fixes: #215

RFC2397 states that data URLs have "no relative URL forms", but
soup_uri_new_with_base would still attempt to resolve any suspected
relative URL paths regardless. This was also inconsistent with the
behavior of most web browsers.

Closes #217

This isn't the proper way to use extern C as the included
headers may actually have C++ aware code in them.

The default was disabled for backwards compatability however it
was an unsafe default and many projects unknowingly did not enable
it.

This is a break in behavior however the security concerns are important.
The belief that all projects would switch to the safer SoupSession
didn't happen and the number of under-maintained projects is too
many to fix quickly.

This brings a base level of security to all of them and will likely
not actually break much as the modern internet depends on CAs heavily.

For users who are broken by it, the possible fixes are:

- Add the CA for the service you can no longer connect to to the
  system CA database on your computer
- Get the administrator of the service you were connecting to to
  switch to using a certificate signed by a public CA
- Use http rather than https
- Wait for, or request, the app to be updated

For system administrators who provide a service whose users have been broken by this, the possible fixes are:

- Update your service to use a certificate signed by a public CA
- Get each user to add the CA to their system CA db, as above
- Get each user to move to an alternative app

For developers of apps whose users have been broken by this, the possible fixes are:

- Document how users can add CAs to the system CA DB, as above
- Add a config option to allow users to turn ssl-use-system-ca-file off again.
  (Note that this will probably eventually result in someone filing a CVE against your app.)
- Add a config option to allow users to configure a file containing a CA to be trusted,
  and then read that in as a GTlsDatabaseFile and set it as SoupSession:tls-database
- Add a ton of code to allow users to accept certificates signed by unknown CAs and then
  remember the certificates for next time. (We have no easily-copied examples of how to do this.)

SoupSessionAsync and SoupSessionSync are growing the new behavior, so
there is no longer any difference to document here.

Meson's wrapdb had both sqlite and sqlite3 but the former is outdated.

With d9f97292 the intention was only to change the behavior of soup_message_headers_get_content_disposition()
however parse_content_foo() is also used for Content-Type.

Fixes #232

Closes #234

A server MUST NOT send a Content-Length header field in any response
with a status code of 1xx (Informational) or 204 (No Content)