Optionally disconnect SWT clients that aren't receiving messages

[liamcary]

Adds an optional max count to the SWT connection sendQueue on the server side. If the sendQueue exceeds this count, the server will forcefully disconnect the connection.

In my testing it is fairly common for a client's websocket to stop receiving incoming messages, whether due to a bad connection, or CPU lag or browser/client errors. If the connection remains open but doesn't send message acknowledgements, the server's SendLoop.Loop will block on stream.Write and the sendQueue can accumulate thousands of ArrayBuffer instances.

This isn't a memory leak as such, since the ArrayBuffers in the sendQueue will be returned to the buffer pool if the client disconnects or the connection recovers. But the memory usage of the server application will be permanantly inflated until the server restarts.

The amount of excess memory without this feature could theoretically be endless, until the application crashes. In many cases the Disconnect Inactive Connections feature would kill stalled clients, but that feature is disabled by default. A very slow/stalled client could also be considered active if its still processing messages, but slower than they are enqueued.

I considered adding a sensible default value, or suggesting a sensible value in the tooltip, but it varies greatly depending on the project. SendRate and batchSend especially will greatly affect the number of messages per second. I currently use this in production on two games with the max count set to 512, using a send rate of 30 and batch send enabled.

This PR conflicts with my other open PR: #4098
If both PR's are merged in, WebsockerServer.Send will need to be updated to return false after disposing a connection due to reaching the max send queue count.