Fix websocket and webtransport multipart callbacks (#698)

[jonathanperret]

The kind of change this PR does introduce

• a bug fix
• a new feature
• an update to the documentation
• a code change that improves performance
• other

Current behaviour

When using the websocket transport, some send callbacks are not called. See #698, and the tests added in the first commit of this PR. The webtransport transport was also found to have the same bug when testing.

New behaviour

All send callbacks are now called.

Also, the type for the callback argument to send() was enriched to reflect the fact that the transport is passed (as it always has been) as its first argument. This does change the types visible publicly, but TypeScript type compatibility rules should make this a non-breaking change (i.e. it's still OK to pass a callback expecting no arguments).

Other information

The bug was caused by the websocket transport (and webtransport as well) having its supportsFraming property set to true, despite having been changed in #618 to emit a single drain event for each batch of messages written to the transport like the polling transport always did. Note that although #618 is partially reverted in a65a047, the new drain event behavior is preserved as called out in that commit's message.

The supportsFraming attribute was introduced in #130 (amended by #132) as a way to distinguish transports that emit one drain per message from those that emit one drain per batch. Since the delivery of send callbacks depends on matching drain events with transport.send calls, that distinction is vital to correct behavior.

However, now that all transports have converged to "one drain per batch" behavior, this supportsFraming property can be retired (and the code for calling callbacks simplified), and this is the refactoring that the last commit of this PR proposes. This is technically a breaking change since supportsFraming was exposed in the TypeScript types of engine.io, but as far as I can tell it was never documented.