Ensure that hooks and error handlers can send standard HTTP replies

[airhorns]

This change fixes a bug in fastify-websocket where the reply object wouldn't actually send anything if it was asked to -- the only think you could do with it is hijack it. Before this change, if you tried to do reply.send or reply.code or what have you, those bytes would never make it out the client. I tested with browsers and with wsocat. The effect of this is that if someone is using an error handler to send errors as HTTP responses, or a validation handler that authenticates or something like that, those responses never make it to the client, but fastify considers the reply sent and is finished with it, leaving hanging sockets and broken expectations.

I think this is an accidental change introduced in #95 when we switched this library to start using fastify's routing and creating this reply object where we never quite set it up right. Now, we do a response.assignSocket with the socket given to us by the websocket server so that the response object can write to it.

Checklist

• run npm run test and npm run benchmark
• tests and/or benchmarks are included
• documentation is changed or added
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

[mcollina]

lgtm