MVP for message tags

[RaitoBezarius]

This enables very basic support of message tags specification.

It has been discussed on #[email protected] with edk and others (thank you a lot for the guidance).

I open this for discussion and having as much feedback as possible.

Implementation plan

• offers an API to register/unregister supported tags in the CLIENTTAGDENY ISUPPORT table.
• message-tags CAP announce
• cap_message_tags module which propagate no tags from incoming message (based on the server time machinery).
• sketch an API to register "hooks" to accept or not a tag from incoming message

Open questions

• s2s behaviors on message-tags (& degradation too.)
• hook API to accept or not a tag can arbitrarly send back an error to client for invalid values, ignore, clamp, do stuff, what is the right way to formalize this?
• feature degradation of certain client tags, e.g. replies, reacts

Advanced feature degradation

The issue is that when m_message module takes the decision to send a message, it provides a Msgbuf buffer structure and pass most of its arguments in a VA list which is not in the Msgbuf structure, therefore, it is impossible to operate on it and convert, let's say, a TAGMSG into a PRIVMSG to degrade it.

Maybe, we could hack for outbound_msgbuf to support getting a pointer to the va_list so we can operate on the arguments and change the current message, but it looks like heavily hacky and dangerous, plus, it's arbitrary string operations because there is no structure at this point in the message saying this is a PRIVMSG, etc. So a quick'n'dirty solution is to msgbuf_parse (more: partially parse, ignore the tags, they are not serialized at this point) the buf.
What I noticed is this mechanism of Msgbuf cache which I do not understand well, which seems to replace progressively the  vsprintf into a buffer stuff.
I assume the intention here is to replace everything with Msgbuf mechanisms.

The only issue I see is that: it still requires to move the outbound msgbuf hook after finalization of the buffer.

Once we can do this, we can tamper with the buf and do nice degradation, plus we can also drop messages silently (e.g. a spammer using TAGMSG +draft/typing=active on all channels.)

Another way would be to slow down the serialization and keep structure at this point or to move the outbound msgbuf hook earlier where there is still structure.

Non-goals

• Facility for channel moderation and filtering a subset of supported client only tags.

Remarks

At some point, we would like to get capabilities for client-only tags so that server can degrade them for unsupported clients (on the basis they creates precious discussion contexts). A suggestion while ircv3/ircv3-ideas#97 is discussed is to use vendor-prefixed capabilities for client-only tags such as solanum.chat/reacts as a capability to test the ideas and implementations.

Nevertheless, any non trivial client-only tag relies on replies client tag and message-ids. Therefore, this is out of scope for this PR for now.

Though, there is a need for filtering client-only tags based on channels (modes?) which will also require specification I suppose and ultimately implementation, this seems to be independant from message-ids and replies client tag.

---

Based on #283.