Add per-Scope event handlers

[vheathen]

Closes #91.

Two libraries in one VM that each bring their own syn_event_handler module cannot both have their callbacks run today: syn has one handler per node, and the last set_event_handler/1 call wins. syn:set_event_handler(Scope, Module) sets the handler of one Scope, and the scope_event_handlers key, a list of {Scope, Module} tuples, does the same for the Scopes that syn starts itself from the scopes key.

Before: one module, chosen for the whole node, runs every callback of every Scope. After: a Scope with its own module uses only that module; a Scope without one uses the node-wide handler from the event_handler key, and syn's defaults when there is none. set_event_handler/1 and the event_handler key are unchanged.

The handler is chosen per Scope, not per callback. If the Scope's module does not export a callback, syn skips that callback for the Scope and does not fall back to the node-wide handler. Without resolve_registry_conflict/4, syn applies its default rule: it keeps the later registration and kills the other process. The edoc of resolve_registry_conflict/4 now says that every node must resolve a conflict in a Scope the same way, which in practice means the same module and version.

The configuration key exists because the scope processes started from scopes exist before host code can call set_event_handler/2, so their first events, the sync with other nodes included, would otherwise go to the node-wide handler or to the defaults. syn fails to start when the key is malformed or names a module that cannot be loaded: starting anyway would leave that Scope without callbacks and with default conflict resolution.

Per-Scope handlers are stored in persistent_term, one key {syn_event_handler, Scope} per Scope. The handler is read on every callback and written rarely, at startup; a persistent_term read is constant time and does not copy the term to the heap. One key per Scope means two concurrent set_event_handler/2 calls cannot lose each other's entry, as a read-modify-write of one list in the application environment could. It also works before syn starts and survives a restart of the application. The cost the persistent_term docs name, a global garbage collection in which all processes scan their heaps when a term is replaced or erased, does not apply here: the stored value is a module name, and deletion of atoms is specially optimized to avoid that GC.

It may make sense to move the node-wide event_handler to persistent_term as well. This pull request leaves it in the application environment so that set_event_handler/1 and the event_handler key behave exactly as before. The price is on the fallback path. Measured on OTP 27 in a running node with 293 applications: reading the handler from the application environment takes 32 ns, a persistent_term hit 17 ns, and a Scope without its own handler (a persistent_term miss, then the environment) 41 ns. With the node-wide handler in persistent_term too, that fallback would take 23 ns.

OTP: persistent_term:get/2 exists since OTP 21.3. syn declares no minimum OTP version; the code so far needed 21.0 (logger and Class:Reason:Stacktrace), and CI tested 21.3 until cf2b318 in August 2024. CI now runs 27 and 28.

Both suites pass on OTP 25.3.2.8, 27.3.4.11 and 29.0.6 (registry 26 cases, pg 14). Dialyzer is clean on 27.3.4.11 and 29.0.6.

Two commits: the function and the selection, then the configuration key. I can squash them if you prefer one.