Release the socket, its loops and the session when disconnecting

[deoxis9001]

What happens today

An ArchipelagoSession is never released after DisconnectAsync, and one of the
three causes below costs a thread pool thread per socket for the lifetime of the
process.

Found on a Discord bot that opens one session per slot at startup, to read what
each player has received. On a 91-slot multiworld this left about 1.8 GB
behind, and it accumulated with every reconnection. A WeakReference to each
session, counted after a blocking, compacting, aggressive gen2 collection,
reported 91 out of 91 still alive — with 0 sockets still open. They were
properly disconnected, and rooted anyway.

Three causes, all in BaseArchipelagoSocketHelper

1. SendLoop blocks a thread pool thread forever

HandleSendBuffer starts with sendQueue.Take(). Take blocks the calling
thread while the collection is empty, and CompleteAdding is never called
anywhere in the library, so it never returns.

Every socket that is opened costs one thread pool thread, permanently. With
enough sockets the pool starves, and since it only injects about one thread per
second, unrelated work starts timing out — websocket handshakes included. In our
case this, not the memory, was what made connections fail: after the fix the same
91-slot read went from 192 s to 124 s, a 35% gain with no other change.

2. PollingLoop cannot be cancelled

ReadMessageAsync awaited Socket.ReceiveAsync(..., CancellationToken.None).
Closing the socket from another thread does not necessarily complete that read,
and an async state machine that is awaiting is rooted by the runtime. Through the
socket helper it holds the event handlers, therefore the session's helpers,
therefore the session and its copy of the data package.

3. The socket is never disposed

WebSocket is IDisposable, and Dispose appeared nowhere in the library.

The change

A CancellationTokenSource per helper, cancelled by DisconnectAsync and passed
to both loops; the send queue is completed; the socket is disposed.

DisconnectAsync is also made idempotent, and its CloseAsync is bounded by a
five second timeout — it waits for the server's close frame, and a server that
never answers would otherwise hang the call forever.

Order matters and is commented: cancel first, then dispose. Disposing first would
make the pending read fail with a disposal error rather than end quietly.

No public API changes.

Measured before and after

Same bot, same multiworld, same machine:

	before	after
sessions still alive after gen2	91 / 91	0 (only the one being collected)
managed heap after a 91-slot read	2088 MB, rising every time	96-124 MB, falling
two 91-slot parties	4776 MB	~150 MB
time for a 91-slot read	192 s	124 s

What I could not verify

I did not run the test suite: it references the library through HintPath to the
net35/net40/net45 outputs, and those targeting packs are not available on my
machine. The change is confined to one file, and the numbers above come from
production rather than from unit tests.