Improve stack trace accuracy by subtracting 1 from each return address.

This should prevent stack traces from spurriously pointing at the line after the one where the call actually happened.

This leaks due to the old compiler bug:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33799
http://llvm.org/bugs/show_bug.cgi?id=12286

Previously we only closed immediately after a response finished.

Add TaskSet.onEmpty() to wait until all tasks have completed

Fixes #286.

I intended to do this, like, 4 years ago.

Revert "avoid passing invalid reference to Array<T> constructor"

Memcpy null src

Revert "Don't read past the end of the base64 decode out buffer."

Don't read past the end of the base64 decode out buffer.

Don't bind Header reference to a null pointer.

Variable-length arrays must have positive bound.

It is invalid to pass null as a pointer argument to memcpy/memcmp/memset, even if the count argument is zero:

> Where an argument declared as size_t n specifies the length of the array for a
function, n can have the value zero on a call to that function. Unless explicitly stated
otherwise in the description of a particular function in this subclause, pointer arguments
on such a call shall still have valid values [...]

Detected by -fsanitize=nonnull-attribute.

If we finish decoding in step_a state, there is no current output character, so reading *plainchar will either be an uninitialized read or (if the output buffer is minimally sized) a past-the-end read.

Detected by -fsanitize=address.

If recvData is empty, recvData.begin() is a null pointer and binding a Header reference to it is invalid.

Detected by -fsanitize=null.

Detected by -fsanitize=vla-bound

Generate ASLR-friendly numeric stack traces.

Add Own<T>::attach() which is much like Promise<T>::attach()

We don't support any extensions currently, but it's important that when acting as a proxy, we don't pass through this header, since it could result in the client and server negotiating extensions that the proxy doesn't understand and will botch.

This is definitely wrong, because it makes the read/write tasks impossible to cancel and possibly makes them outlive the buffers they are reading from / writing to.

I have no idea why I wrote the code this way, TBQH.

Don't reuse HTTP client connections if the previous request didn't read the entire response.

(Or if it didn't send the entire request body.)