fix: correctly handle buffered data from hijacked conns (#76)

I think I've finally realized what's causing the flaky test failures
described in #72. As noted in [a follow-up comment][1]

> if I add code like [2] to wrap the client and server connections
> and record the bytes each reads and writes, it looks like the server
> sometimes fails to read the first byte from a given write by the
> client.

This smelled a bit like buffering somewhere, and it turns out that
we were intentionally (and misguidedly) discarding the buffered
reader/writer returned by [Hijack][3] when capturing the connection
underlying an HTTP request:

    conn, _, err := hj.Hijack()

And it turns out that the Hijack docs explicitly warn us that we may be
discarding buffered reads (e.g., maybe the first byte written by a
client):

    // The returned bufio.Reader may contain unprocessed buffered
    // data from the client.

So! Here we update our `Websocket` to read through that buffer for all
reads, while still writing directly to the underlying `net.Conn`. This
should hopefully fix #72.

(Plus, a few misc test updates.)

[1]: #72 (comment)
[2]: 06e053e
[3]: https://pkg.go.dev/net/http#Hijacker

security: pin all github action versions (#57)

refactor: consolidated error/status code handling (#40)

Here we provide a standardized way to map errors to close codes, and
take a naming pass through our errors and codes to better align them
with the IANA's registry of WebSocket Close Codes[1].

[1]: https://www.iana.org/assignments/websocket/websocket.xhtml#close-code-number

test: add additional tests for failure modes (#36)

Plus, promote `Hanshake()` to the public API in support of those tests.

test: add additional tests for failure modes (#36)

Plus, promote `Hanshake()` to the public API in support of those tests.