v4.

I've decided it's probably better to abstain from exporting the input
validation hooks or their members without good reason. Likewise for the
hook involving split-lines and command-detection. So they've all been
renamed as internal, for now.

This version also brings with it some out-of-scope feature creep in
response to recent clamoring for a way to prevent all multiline input.
I've therefore added two options and wired them into the pre-send
validation mechanism introduced earlier in this series. The first is
called `erc-inhibit-multiline-input', which must be either a positive
integer or t. As an int, it indicates the maximum number of lines
allowed to be submitted for sending (above which a beep and a scolding
result). The second is called `erc-ask-about-multiline-input'. When
non-nil, instead of getting scolded, the user is asked whether to go
ahead and send anyway (just this once).

A few (arguably surprising) idiosyncrasies surround the interaction
between `erc-send-whitespace-lines' and these newly proposed options,
but nothing too radical or inconsistent (IMO). For example, during the
reckoning of `erc-inhibit-multiline-input', trailing blanks are always
trimmed, but when `erc-send-whitespace-lines' is nil, this becomes
irrelevant because the send is preempted beforehand, which is in line
with the behavior described in the initial bug report.