Events are classified by room connect ("@system", "world.openverse.com:7000",
etc.), by source ("user12", "xfer3", "server", etc.), and by type ("chat,
"enter", "leave", "move", "rename", etc.).  Event listeners specify filters on
these classifications to reduce spurious notification.  Hmm, I should probably
divide source into source-type ("user", "xfer", "server", "text", etc.) and
source-name ("12", "Unununium", etc.), to allow a listener to accept events
from entire source-types.
- room --- Location of source
- class --- Type of source
- name --- Identifier for source
- action --- Event attributed to source
An empty list for room, class, name, or action filter means do not disqualify
events based on this criteria, otherwise only events matching na item in the
filter list are allowed through.

There are three priorities for event handlers.  Event handlers are called in
order of decreasing priority (high to low).  Within a priority, event handlers
are called in arbitrary order.  If an event handler signals that an event
should be vetoed, then lower-priority event handlers do not receive the event.
High priority is signified by "1", medium by "2", and low by "3".  This is
intended for client-side ignore.  Logging should be high- or low- priority, as
appropriate, and ignore should be medium-priority.  Non-debug user display
should be low-priority.