OS-specific behaviour is not necessary. This PR replaces filepath.Match
with path.Match and also updated the documentation to reflect that.

Closes #451

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

Client "Sec-WebSocket-Key" should be a valid 16 byte base64 encoded
nonce. If the header is not valid, the server should reject the
client.

Unacceptable offers are declined without rejecting the request.

Also ran gofmt on everything. Thanks again @paralin. #334

Co-authored-by: Christian Stewart <christian@paral.in>

Closes #247

HTTP header values, as opposed to header keys,
are case sensitive, but implementation of headerTokens()
before this patch would return lowered values always.

This old behavior could lead to chromium (v87) WebSocket
rejecting connnection because negotiated subprotocol,
returned in Sec-WebSocket-Protocol header (lowered
be headerToken() function) would not match one sent
by client, in case client specified value with capital
letters.

See: https://staticcheck.io/docs/checks#SA4001

Closes #220 and #230

Closes #166

Closes #235

It's more clear than * as an origin pattern.

Closes #218

Closes #199

Closes #194

Closes #189

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

Closes #182