This will create easily solved breakage on updates but
I figure it's best to pull the band aid off as early as possible

This is a cleaner solution for the fix in #438 thanks to the fact that Go 1.19 now is the default and the atomic.Int64 types are automatically aligned correctly on 32 bit systems.

Using this also means that xsync.Int64 can be removed. The new atomic.Int64 type solves the issue and should be quite a lot faster as it avoids the interface conversion.

Far simpler now. Sorry this took a while.

Closes #427
Closes #429
Closes #434
Closes #436
Closes #437

Whoops, updates #254 and closes #410

Whoops.

Closes #330

Closes #330

Closes #400

Closes #349

NetConn has to close the connection to interrupt in progress reads
and writes. However, it can block reads and writes that occur
after the deadline instead of closing the connection.

Closes #228

This way we don't pollute the directory tree.

Updates #209

Closes #199

See https://github.com/nhooyr/websocket/issues/182

Closes #182

Too many improvements and changes to list.

Will include a detailed changelog for release.

- 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

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.

Subprotocols didn't work with WASM at all before.