This bug presents an opportunity for revisiting how input handling and
pre-send hook management happen in ERC. The groundwork has already been
laid by ERC 5.5, so we might as well try inching closer to something
more responsive and intuitive. This being ERC, flexibility is also a
priority, but for now, I'm thinking we should focus on honoring existing
interfaces rather than adding new ones.

In the current envisioning (v2 attached), this imagined shift toward
smarter input handling starts by moving all line splitting and related
input preparation forward so it runs earlier, alongside the various
validation checks. Doing this alone could, for example, give us
friendlier feedback when crossing the `erc-inhibit-multiline-input'
threshold, with the rejected goods being invited to hang around in the
prompt area for successive tweaking and do-overs (instead of seeing
their mutilated pieces clutter up the kill ring, which more or less
describes the current state of affairs).

The path I'm proposing does come with one minor hiccup in terms of
corner-case breakage, but only for third-parties that expect
protocol-length line splitting to occur after the more send-focused
hooks run (chiefly, `erc-pre-send-functions'). To smooth things over,
I'm proposing an off-by-default compat switch, which would manifest as a
new "refoldp" slot for the `erc-input' object that's shared among these
hook members. Third parties can toggle this on if they'd rather not
trust other members to perform the necessary bookeeping to keep line
lengths in check.

If you'd like to try this, just

  (setq erc-inhibit-multiline-input t
        erc-send-whitespace-lines t)

and submit a long passage at the prompt.