SoupConnection was generating its own :event signals for
TLS_HANDSHAKING/TLS_HANDSHAKED, since we don't use GSocketClient's TLS
negotiation, and so just re-emitting the socket client signal won't
cover that.

However, it ended up emitting it before the SoupSocket had even
created the GTlsClientConnection, and so was emitting it with the
GTcpConnection, contrary to the documentation.

Fix this by making the SoupSocket generate those event signals at the
correct time, and having SoupConnection just re-emit them. Also, add
code to connection-test to verify that each even is emitted with the
expected kind of GIOStream.

https://bugzilla.gnome.org/show_bug.cgi?id=739951

https://bugzilla.gnome.org/show_bug.cgi?id=729987

https://bugzilla.gnome.org/show_bug.cgi?id=729987

https://bugzilla.gnome.org/show_bug.cgi?id=729987

When using chunked encoding, SoupBodyOutputStream needs to write the
final "0" chunk when it's closed, and thus may block. So we have to do
an async close in the non-blocking case.

(This also requires changing continue-test to not trace "finished"
events, since it becomes unpredicatable exactly when they'll happen
now.)

https://bugzilla.gnome.org/show_bug.cgi?id=727138

Document what features exist on a SoupSession by default.

Suggested by Michael Catanzaro.
https://bugzilla.gnome.org/show_bug.cgi?id=737689

Avoid the use of 'interface' variable name in public headers to avoid
conflicting with the "#define interface struct" that Windows headers do.

https://bugzilla.gnome.org/show_bug.cgi?id=738551

Added a note that this API is only meaningful in the context
of a SoupSession (i.e. it's not meaningful for a SoupServer).