Re-add the event system library so that events can be monitored (for testing purposes)

[rdw-software]

This is the global event registry from evo-luvi (see RFC), but it should be able to buffer events and payloads for testing purposes.

Using event emitters makes the code less decoupled and it's a bit of a pain to test whether a server has received some data, for example, which was a problem I encountered when writing tests for the TCP server before. I basically had to write a lot of boilerplate code, when I think it might be easier to just enable the event buffer, do the thing, and then fetch the events and compare to a list.

Goals:

• Can buffer events internally and retrieve them (for logging and testing purposes)
• Can register and unregister handlers for events (arbitrary functions)
• Defaults to a standardized CAPITALIZED_EVENT_NAME handler unless otherwise specified
• Can mix in the most commonly-used APIs to enable more convenient "event emitter style" usage (obsolete?)
• Attempting to register handlers for unknown events fails loudly
• New events can be trivially added to enable extending the event system with non-standard events

[rdw-software]

Parts of this are already covered by #376. The rest will follow later, once I've found a design that doesn't completely annoy me.

[rdw-software]

As for event handlers: It would be conceivable that etrace.register (and etrace.unregister) get a second argument, the handler function. These could then be stored internally alongside the enabled state of each event, possibly with a string identifier/label. Something like this maybe:

local etrace = require("etrace")

etrace.register("COFFEE_READY") -- Defines the event, but no handlers exist (optional)
etrace.enable()

local Programmer = {}

function Programmer:COFFEE_READY(event, payload)
  print("Yay!")
end

etrace.register("COFFEE_READY", Programmer)  -- NO error even though the event is known, because of the 2nd argument

etrace.create("COFFEE_READY")

When executed, it should print Yay! (and not throw because of the second call to etrace.register). Anyway, just an idea.

[rdw-software]

Coming back to this, I don't like how the above design would complicate the interface and logic for etrace.register. Instead:

• Registering a listener could be done via etrace.listen, etrace.subscribe, or a similarly-named function
• Once a listener has been registered, it can receive updates published via etrace.notify(event) (or via polling)
• It's unclear whether event listeners should be unregistered; probably? If so, might need etrace.unsubscribe or similar?
• It might be worth adding a shorthand for combining record and notify, in this case called etrace.publish?

A global EVENT shorthand for the common sequence of register + record + notify could also be introduced.