* don't send multiline responses to CAP LS 301

This is more or less explicitly prohibited by the spec:

https://ircv3.net/specs/extensions/capability-negotiation.html#multiline-replies-to-cap-ls-and-cap-list

* switch to whitelist model to be future-proof

* bump irctest to include test

* add a unit test

* Makefile: Add dependencies between targets

* Implement draft/message-redaction for channels

Permission to use REDACT mirrors permission for 'HistServ DELETE'

* Error when the given targetmsg does not exist

* gofmt

* Add CanDelete enum type

* gofmt

* Add support for PMs

* Fix documentation of allow-individual-delete.

* Remove 'TODO: add configurable fallback'

slingamn says it's probably not desirable, and I'm on the fence.
Out of laziness, let's omit it for now, as it's not a regression
compared to '/msg HistServ DELETE'.

* Revert "Makefile: Add dependencies between targets"

This reverts commit 2182b1da69.

---------

Co-authored-by: Val Lorentz <progval+git+ergo@progval.net>

CHATHISTORY TARGETS response should not be in a batch unless the client has
explicitly requested the batch cap.

In #2058 we introduced two bugs:

* A nil dereference when an outside user attempts to speak
* Ordinary copy of a modes.ModeSet (which should only be accessed via atomics)

This fixes both issues.

* tweaks to NAMES implementation

* tweak member caching

* add a benchmark for NAMES

See #2052

Remove `<no reason supplied>`, make default KILL anonymous

Fixes #2048

* implement draft/pre-away
* clean up some subtleties in auto-away aggregation.
* consistently apply auto-away only to always-on
* `AWAY *` should not produce user-visible changes wherever possible

https://github.com/ircv3/ircv3-specifications/pull/510

See #2037

Sanitize the in-band error message from REHASH

Fixes #1782

Also stop attaching the *tls.Config to the wrapped connection,
since this forces it to be retained beyond its natural lifetime.

Provide a nondestructive stack trace dump option even when the http pprof
listener is disabled

TAGMSG should not get automatic RPL_AWAY replies

Add WHO responses for services

Kiwi expects it due to https://github.com/kiwiirc/kiwiirc/pull/1244 , but
the corresponding spec change only altered the cap name, not the 005 name.

Unclear where we got draft/CHATHISTORY from, it looks like the merged drafts
have always used unprefixed CHATHISTORY as the token name.

* fix #2002

`CS AMODE #channel +f nickname` is invalid, but was being accepted
incorrectly.

* simplify logic

https://github.com/ircv3/ircv3-specifications/pull/508

According to the de facto standard, `AWAY :\r\n` is equivalent to `AWAY\r\n`.
Our behavior was inconsistent before, now it consistently matches the de facto
standard.

See #1994

WHO <nickname> should not respect +i

See 69448b13a1 / #1969; the compiler can now ensure that a uint64
intended for atomic access is always aligned to a 64-bit boundary.
Convert atomic operations on uint32s and pointers as well.

Sanitize ::1 to 0::1 in WHOX output

On a 32-bit architecture, 64-bit atomic loads and stores must be aligned to a
64-bit boundary. Since the (mysql.MySQL) struct is directly included in the
Server struct, it is impossible to guarantee this via the standard technique
of putting the 64-bit value at the beginning of the struct definition
(since the point at which it is included in the parent struct may cross a
64-bit boundary).

This optimization is probably pointless anyway, adding an additional
indirection won't make a difference.