New plugin callback to know when datachannel is writable

[lminiero]

This patch adds support for the SCTP_SENDER_DRY_EVENT event from usrsctplib to our SCTP stack, which helps us with two main things:

1. It tells us when a datachannel first becomes available: in fact, plugins cannot rely on setup_media for that, since that only tells you when ICE+DTLS have succeeded (and so the PeerConnection is up and running), but not that datachannels are available too. For that you need for the SCTP setup to complete too, and that's what the first SCTP_SENDER_DRY_EVENT event tells us.
2. It also tells us any time a datachannel becomes writable again, or more precisely when its internal buffers are empty. This helps solving another issue, that is trying to send too much data and the SCTP stack rejecting it or even closing: with a callback that is invoked any time you can start sending data again, it's easier to throttle/schedule the delivery of outgoing data.

This is tied to a new plugin callback called data_ready:

/*! \brief Method to be notified about the fact that the datachannel is ready to be written
 * \note This is not only called when the PeerConnection first becomes available, but also
 * when the SCTP socket becomes writable again, e.g., because the internal buffer is empty.
 * @param[in] handle The plugin/gateway session used for this peer */
void (* const data_ready)(janus_plugin_session *handle);

It's not mandatory to be implemented by plugins, but all our stock plugins make use of it one way or another. This includes Lua and Duktape, which invoke the dataReady() callback in the respective language on the loaded script, if implemented.

This patch also adds some partial support for SCTP pending messages. If a message you're trying to send is too large for the SCTP to send, it will buffer it internally, and then try to delivery it in chunks later. We don't have a cap in there at the moment, but I'm thinking we should: if you're thinking of abusing it to just pass a humongous amount of data to the stack, notice it will perform crappily, if not crash entirely. You should use the data_ready callback instead to do this in a more sensitive way.

Still experimental but seems to work (tested briefly), so feedback welcome: if you're planning to use it, please test and let me know if it does its job, and there are no regressions.

[lminiero]

I think I'll just merge as it is. We can fine tune it as more people use it, since as usual keeping it in a PR didn't result in any feedback at all.