Medical Vitals - Extract update logic to separate functions

[LinkIsGrim]

When merged this pull request will:

• Makes more sense IMO. Intent is for events to be used as API (IV medication/incompatible blood transfusions, for example).

Event deferral is just to keep any code from the events out of the vitals counter, but they can just be raised straight with no problems.

IMPORTANT

• If the contribution affects the documentation, please include your changes in this pull request so the documentation will appear on the website.
• Development Guidelines are read, understood and applied.
• Title of this PR uses our standard template Component - Add|Fix|Improve|Change|Make|Remove {changes}.

[LinkIsGrim]

On another note:

• VAR_HEMORRHAGE doesn't have any usage (and I don't think it's API?)
• VAR_IN_PAIN could be replaced with a comparison with GET_PAIN_PERCEIVED > 0 (which is what is done in the state update, point is, we could drop the network update by doing a cheap comparison)

Drop 'em?

[johnb432]

Key can't be an object, you need to use hashValue first.

[johnb432]

Generally not a huge fan of having a global hashmap for this kind of thing:

1. If the unit is deleted, you need to handle the removal from the hashmap.
2. If the unit switches locality, this can't handle it. Idk how important that is though.

Why not use an object variable instead? Handles 1) and no longer requires hashValue _unit.

[LinkIsGrim]

hashmap is slightly faster (might not be with hashvalue), that was the only incentive. If we don't have to worry about keeping 3rd-party code out of the counter, I'd rather just raise the events outright.
locality change and deletion won't (shouldn't) happen mid-execution, deferred events are still executed on the same frame, so it'll be either before or after handleUnitVitals is executed.

[johnb432]

I'd rather just raise the events outright

Do that then, makes more sense.