Simplified event handling

[GregHib]

Events are currently stored in a Trie which is a middle ground between efficiency, complexity and flexibility. See #324

Having a 1:1 relationship between possible actions and handlers should be the simplest solution and give the best possible performance, flexibility doesn't matter as much as this is how runescript already handles it.

Being overly flexible in the past has allowed complexity in behaviour where one piece of content indirectly overrides another. This is great for modularity but adds implicit dependencies between things, combat being the main example.
Ideally the event system should not be dependent on overriding or order.

Untying

Attempts were made in #324 to reduce the amount of interdependency but still some content remains that requires implicit order of execution dependencies on others. This needs removing before moving to a different system.

Matching

The trade off to be made is how and when to match a handler with an actor. In a pure 1:1 world, the developer would have to manually write a setter for every single entity. With entity counts being approx 200k this is impractical especially as handlers are shared and reused often e.g. nearly all bankers have the same dialogue.

So there must be a way to match multiple entities, the current system uses id Wildcards. This is fine except storing all of the wildcards and checking them against an entity at runtime isn't as efficient as it could be, although a trie is implemented to be faster than looping every wildcard it has added complexity to every event.

The obvious alternative is to filter the list of entities using the wildcard on startup, e.g. to fill in a Map<Entity, Handler>.

The issue with this is performance as a naive approach of checking every entity against every wildcard will be slow. E.g. 100 wildcards tested against 50k entities is 5m iterations.

The current handler count is at just under 2k, and will grow substantially as more content is added.

[GregHib]

Best options seem to be:

1. Store wildcards and matchers in a trie and use the trie to lookup handlers for every entity on startup, then dispose of the trie keeping a 1:1 map.
2. Group entities by categories for faster lookups (e.g. human, banker, attackable) etc..

That should minimise the impact on startup, assuming it's negligible the deciding question would be how much extra memory would the 1:1 map take-up.

This will be hard to estimate as use on handlers will take up more spaces than individual handlers.

It would also depend on whether there's a default handler. For example "Attack" is handled by a single entry, instead of adding it to all 30k npcs.

[GregHib]

1. has issues as not all the values are known upfront. E.g. the number of slots for an interface. The number of parameters would have to be cut down significantly
2. only alleviates the problem, it requires adding categories to definitions, which needs doing anyway but should be done first/separately

For now it might be worth focusing instead on untangling the implicit dependencies, removing all the instances of override and generally simplifying Events, might be an idea to separate emit and broadcast to remove that variable from all events.

[GregHib]

Interfaces will be better to use the interface:component format to identify matching against a specific component, or all if no ':' exists.