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.

NS SAREGISTER should send machine-readable responses. A simple approach:
check if the account-registration cap is enabled, and if so, send the
the same responses that would be sent by the REGISTER command.

See #1593; this enables a client-side implementation of bulk deletion

Reported by @Mikaela

* Add ACCEPT-tracking functionality (authorizing users to send DMs
  despite +R or other applicable restrictions)
* Sending a DM automatically accepts the recipient
* Add explicit ACCEPT command

Add more clarify in NS INFO and SAREGISTER about unregistered nicknames

Fixes #1924

KLINE'd clients would produce a QUIT snotice without a corresponding
CONNECT snotice; explicitly suppress the QUIT snotice.

Log it at level INFO for parity with connect / connect-ip

RPL_WHOISCHANNELS didn't have proper line breaks

`NICK :` pre-registration needs to be special-cased to immediately
send ERR_NONICKNAMEGIVEN (unlike erroneous nonempty nicknames,
which are processed when registration is complete)

If the nickname must equal the account name (because always-on or
force-nick-equals-account), the correct error response to an empty
or otherwise invalid nickname is the usual "You must use your account
name as your nickname".

LIST should not return ERR_NOSUCHCHANNEL for nonexistent channels

DEFCON 4 and lower were blocking SAREGISTER. This is wrong; admins should be
allowed to make new accounts even under DEFCON (this may be needed
specifically to work around the DEFCON restriction).

* Fix #1911 +s channels don't appear in /list even though on the channel

* use channel.HasClient instead of custom iterative checker

Include server start time in INFO output.