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.

Having the 'samode' capability made all KICK commands privileged. This appears
to have been introduced unintentionally by 42316bc04f and I can't find
any discussion of a rationale. Since this goes against our policy that all
ircop (as opposed to channel founder) privileges must be invoked explicitly
(e.g. SAJOIN, SAMODE), remove this.

Don't allow any new uses of 0 as a nickname, since it conflicts with
the use of 0 as a placeholder for account name in WHOX.

AMODE +v should allow you to join a +i channel

NS SAREGISTER would fail due to a nil dereference of `client`;
add two safeguards against this.

This extends #1650 to cover WHO as well as WHOIS

See discussion on #1891

* optionally protect against multiple starts with flock

Fixes #1823

* use traditional .lock extension

* move config key to top level

INVITE did not exempt from +b unless the channel was coincidentally also +i.
This was a regression introduced in v2.4.0.

The arithmetic was assuming that the nickname is * (which it is
pre-registration). However, we were sending the actual nickname
post-registration. It would be simpler to always send *, but it
appears that the nickname is actually required by the spec:

>Replies from the server must [sic] contain the client identifier name or
>asterisk if one is not yet available.

See #1858: this was the intent all along, but I missed this issue.