• Add event ignoring or entry for revoking loot (both have same purpose) to Loot History UI. Make sure it propagates the point (DKP) change properly also. Covers #23
• Add point entry ignoring in point history. Covers #21
• Add Raid creation event ignoring. This might be tricky as there will be lots of events depedent on that creation so to optimise stuff we could ignore a batch of events
• Add Inspection UI that lists information about all the events in the ledger and allows ignoring them. Only Managers should be able to do that. UI should show:

• some basic information (class, name [human readable that we will define just for the UI], time, creator)
• Ignore events should list (on hover?) events they ignore or show ignored events as grayed out and add option to unignore them
• Add option for batch ignoring (@SamMousa this will need change in the library that we need to decide upon) where selecting 2 entries would ignore them and everything in between (with library change this would be single IGN entry internally)

Ignoring time ranges is a very bad idea; you don't know what's in between there that you don't have.

Instead we should be smart and have proper error handling in mutators.

Imagine ignoring a CREATE RAID WITH LABEL ABC event.
Now all mutators that depend on it should just ignore events that they can't handle.

So an event ADD PLAYER X TO RAID ABC is just ignored because raid ABC does not exist.

If batching is still needed it will be implemented by explicitly passing a list of events to be ignored. Regardless of this, mutators should not crash but handle missing data reliably.
In most cases that will mean just silently be a NOOP if data you need is missing; either it will come in later via a sync, at which time we will restart and rebuild state, or it won't come in because it has been ignored in which case NOOP is the right behavior.