bug#73798: 31.0.50; ERC 5.7: New extensibility focused match API

[J.P.]

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

> v3. Replace `erc-match-types' with `erc-match-functions', an actual
> (abnormal) hook. Update docs as mentioned in previous post.

In the imagined use cases described up thread, it likely won't be
uncommon for a module to manage multiple match types, with multiple
members in `erc-match-functions' and `erc-text-matched-hook'.

Related predicates, handlers, and methods may therefore need to
communicate across matches, for example, to know whether a match has
already occurred for the current message. So it may well make sense to
add another slot to the base type whose value is shared among all
objects during matching and filtering. An alist probably makes the most
sense for this.

If knowledge of prior matches turns out to be desirable and commonplace
enough, we can keep and expose a record of all successful matches.
(Doing this might further justify the current "split" design with its
distinct predicate and handler phases.) One slight challenge here would
be the necessity for some form of indirection to access such a record
(because tacking on a list of prior match objects as a visible "has a"
property of later objects would make printing them somewhat nasty). So,
instead of another slot, we could maybe offer an object-retrieval
utility keyed by constructor function.