There's not many useful things we can do with this log, other than
providing a way for downstream applications to identify those logs.

Comparing the int is a very cheap operation, and it is also a very good
indicator already that we've found the right event. Due to the short
circuiting behaviour of &&, it is better to check that first before
doing the Log::is_boss check - which is relatively costly. Remember that
we do this check for every buff application event!

This brings a speedup of around 50x:
new:    654.1±25.18µs
old:    34.9±0.69ms

If the reward has been given out, we can be 99.9% sure that the fight
succeeded, in which case we don't need to do any other convuluted
checking. This has the benefit of catching some false-negatives (edge
cases in success detection), at the cost of making the detection a bit
... weirder, in the sense that a log's success might now depend on
whether it was the first kill in the week or not.

However, given that our sucess detection works pretty well overall, I'd
say it's worth to catch a few more false-negatives and try to classify
as many logs correctly as possible. At least, this does not introduce
any false-positives.

This is now the enum that contains the IDs of the single bosses, like
Nikare and Kenut. This means we can do away with the NIKARE_ID and such.

The enum is not publicly re-exported, as we re-export Encounter (which
is more of a replacement of the old Boss).

Special casing still remains (mostly in lib.rs), but we should be able
to do away with this now with a more general Encounter::bosses and
Boss::encounter methods.

This is the first step in differentiating between Encounters and Bosses.
It sounds a bit weird at first, but there are some events without any
bosses (like the River of Souls), and some events which have multiple
bosses (like Twin Largos or the kodan strike mission). If we want to
support this better, without relying on extra IDs, special casing and
constants (like NIKARE_ID), we should differentiate between Encounters
and Bosses.

Since downstream applications will also print this, we should remove it.