See https://github.com/golang/go/issues/31586#issuecomment-550040882

Thanks @renthraysk

benchmark                      old MB/s     new MB/s     speedup
BenchmarkXOR/2/fast-8          470.88       492.61       1.05x
BenchmarkXOR/3/fast-8          602.24       719.25       1.19x
BenchmarkXOR/4/fast-8          718.82       1186.64      1.65x
BenchmarkXOR/8/fast-8          1027.60      1718.71      1.67x
BenchmarkXOR/16/fast-8         1413.31      3430.46      2.43x
BenchmarkXOR/32/fast-8         2701.81      5585.42      2.07x
BenchmarkXOR/128/fast-8        7757.97      13432.37     1.73x
BenchmarkXOR/512/fast-8        15155.03     18797.79     1.24x
BenchmarkXOR/4096/fast-8       20689.95     20334.61     0.98x
BenchmarkXOR/16384/fast-8      21687.87     21613.94     1.00x

Now its faster than basic XOR at every byte size greater than 2 on
little endian amd64 machines.

Fix race with c.readerShouldLock

Closes #168

CODEOWNERS is unnecessary.

Fix concurrent read with close

Closes #164

Switch to coveralls.io from codecov.io

No need to test both client and server side.

codecov's uploader keeps failing due to the API being unresponsive and the UI is cluttered
compared to codecov.

- For JS we ensure we indicate which size initiated the close first from our POV
- For normal Go, concurrent closes block until the first one succeeds instead of returning early

Much faster.

Should not fail now that I've adjusted the chunk size.

Implement complete close handshake

I changed my mind after #103 as browsers include a wasClean event to indicate
whether the connection was closed cleanly. From my tests, if a server using
this library prior to this commit initiates the close handshake, wasClean
will be false for the browser as the connection was closed before it could
respond with a close frame. Thus, I believe it's necessary to fully implement
the close handshake.

@stephenyama You'll enjoy this.

Add websocket.CloseStatus

Will make it much more convenient and less error prone to access
the StatusCode of a *CloseError.