core: Implement echo-message, disabled by default

core: Implement echo-message, disabled by default

Implement the IRCv3 "echo-message" capability, allowing Quassel to
show how the network displayed sent messages, including any added
latency.

As this introduces additional latency, don't request this by default.
It can be manually activated with "/CAP REQ echo-message", e.g. in the
list of commands to perform on connect.  There may be other issues as
well, such as with CTCP handling.  Here be danger!

This will serve as the building block for communicating when a message
is pending being sent, vs. being delivered.  This requires support for
IRCv3 "batch" and "labeled-response", alongside protocol changes to
allow updating the status of existing Message objects.

Also add missing sources of setting the "::Self" flag on messages,
ensuring that echoed messages will be properly handled, e.g. with CTCP
events.

[Original commit by justJanne, made opt-in by digitalcircuit]

See https://ircv3.net/specs/extensions/echo-message-3.2.html
And https://ircv3.net/specs/extensions/labeled-response

[Addendum]
If "echo-message" was to be made enabled by default as-is, the
Features tab in the Network settings page can offer a way to opt out.

Here's how it might look:
Checkbox with widget name of "enableCapEchoMessage":
[x] Show outgoing messages after delivery

Tooltip:
<p>Wait until the IRC network has received the message to show it in Quassel, and show any changes the network has made to the message (e.g. removing formatting).</p>
<p>It may take longer for outgoing messages to appear.</p>
<p><i>Toggles the IRCv3 'echo-message' capability.<i></p>

"echo-message" should not be enabled by default yet, I just spent a
fair bit of time thinking on how to phrase this and wanted to preserve
it in the unlikely case it is useful in the future.

And here's the reasoning to go with this now-theoretical commit:
Reasoning:
This will unavoidably add latency to showing messages you've sent, and
if a network incorrectly echoes messages back, this could result in
losing message history.  Some may prefer the lower-latency of having
Quassel locally show messages, and we're a fair distance away from
implementing message labels in order to provide a "sending"/"sent"
message feedback (or any form of message editing at all) - messages
are assumed to be immutable once received.