It makes sense to expose this logic as a function, as other programs
like raidgrep might want to use the same logic when dealing with partial
evtc files.

Just like with Event, we now have Agent defined in its own submodule.
The amount of code that it entailed was a lot, so it made sense to split
it off, especially with the deserialization being another big chunk of
Agent related code in lib.rs

The main issue was that the processing submodule accessed private fields
of the Agent struct, which is now no longer possible (since processing
is no longer a submodule of the module in which Agent is defined).
Therefore, some simple crate-public setters for those fields have been
added. Those setters are not public because we do not want outside
crates to mess with the innards of Agent (yet).

Although with (de)serialization being a thing, we need to ensure that we
can handle nonsensical values anyway, since we can no longer guarantee
that we have full control over all of the values, even without setters.

The rationale is included in the comment below. The gist is that we want
to avoid deserializing Agent<Player> (and others) directly, as that
would circumvent the checks.

As a small bonus, we now skip the phantom_data field in serialization,
as that's just an implementation detail that other consumers shouldn't
worry about.

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.