v2. Only update `erc-channel-banlist' if initialized. Redo shared hook
mechanism for buffer truncation.

"J.P." <jp@neverwas.me> writes:

> Both for clarity and compatibility with the current behavior, I think we
> should instead keep `erc-channel-banlist' empty (and locally unbound)
> until formally initialized for a given channel within an ERC session. An
> easy way to do that would be to guard the above like so:
>
>   (when erc--channel-banlist-synchronized-p
>     (erc--banlist-update state arg))

I've done this in the latest set of patches (attached).

I've also tacked on a reworking of the rather awkward hook mechanism by
which modules can run code prior to a buffer's truncation. This was
previously handled by the abnormal hook `erc--pre-clear-functions',
which was run by both the `truncate' module and the `erc-cmd-CLEAR'
slash command. Part of this overhaul involved deferring most of the code
that formerly ran on `erc-insert-done-hook' to a per-response, ephemeral
`erc-timing-hook' member.

The main reason for this move is to escape the insertion related context
imposed on such hooks by response-handling code further back in the call
stack. We're not inserting anything, so it makes little sense to abuse
such hooks for their side effects, which is a design flaw and a common
antipattern (though an excusable one, seeing as there's no real sensible
alternative). Regardless, deferring to a known call site over a limited
extent via `erc-timer-hook' seems far more predictable and manageable
than relying on `run-at-time' or similar.