Fix SSL sessions returning uninitialized memory

[SeanTAllen]

SSL.read sized its buffer from the length it was about to request, then returned that size as the number of bytes decrypted. On two of its exits those numbers did not match, and the caller got uninitialized heap back as application data. SSL.send had the same defect against BIO_read and gets the same fix.

read also had two SSL_read call sites, one that truncated the buffer on some exits and one that truncated on none. It has one call site and one truncate now, so a path that skips the truncate can't be written.

SSL_get_error results were matched as bare integers in read and receive; they are named values on a _SSLErrorCode primitive now. The dead max binding #117 names was part of the sizing logic being rewritten, so it comes out here too.

The if pending > 0 clamp is an allocation bound now, not a correctness guard. Shrinking len to SSL_pending's count used to be what kept the returned size right. The size comes off SSL_read's return on every path now, so the clamp only bounds the allocation. Delete the whole block and every test still passes with every returned byte correct.

Reaching the two new lines in send takes two gibibytes or more of queued ciphertext, the case #121 narrows to. Both lines can be deleted with the full suite green.

The missing else on the SSL_get_error match, #120, is now reachable from a path that could not reach it before. Previously only the SSL_pending == 0 path reached it.

Five open issues cite ssl/net/ssl.pony line numbers we move here: #118, #119, #120, #121, #122. Renumbering isn't enough for #121. It describes read as having two SSL_read call sites and says send returns uninitialized heap to the peer, and neither holds after this.

Closes #123
Closes #117