Fix wrongly shown soldiers & Refactor HQ start wares and inventory handling

[Flamefire]

When soldiers in the leave queue get cancelled, e.g. because a fight
started so we re-add all leaving aggressive defenders, the counts of
soldiers gets off:

• Adding a soldier to leave queue will remove it from the real count
  only, not the visual count: He is still in there
• When he is removed from the queue after going out the visual count is decreased
• When adding it back before he left we must not increase the visual count

Currently it checked if the soldier is in the leave queue but at that
point he isn't anymore so the check never succeeds.

Add new callback to notify when a figure has left the queue.

Fixes #1907

I added tests for this issue and possible related issues I could see by inspecting the called code.
For that some additional changes were required:

1. In replay mode the "pause" command needs to be ignored. We store that as a "GameCommand" so jumping through the provided replay stopped in the middle which confused the remaining code which looked like the whole game froze (some code assumed it is still fast-forwarding)
2. For testing I needed a HQ with a given number of soldiers but adding start wares when creating the HQ instance means I get some unknown number of soldiers that I could not remove easily. So factor out a method for adding start wares and do it where and only when we need to (at the start of the game). This also avoids the "issue" where the place-HQ cheat added wares which it shouldn't
3. Adding wares and/or people to warehouses was awkward: Through Inventory via AddGoods. So you needed to create an "inventory" of soldiers to pass to AddGoods?
   GoodsAndPeopleCountsis now both aGoodCountsandPeopleCountsallowing them to be used as required. RenamedAddGoodsto 3AddToInventory` methods to avoid parts of the work if only people or goods are added.
   Factory functions for adding single job/people types

The additional tests yielded further changes to address this:
When a defender is called it stops leaving attackers and aggressive defenders (interception enemy attackers) from leaving the house.
The callback to provide a defender will use leaving soldiers if necessary. So we can stop them first to always have those we will stop anyway.
As that method to stop them was hard to name and was now only called in a single place with assumptions at both sides I eventually just inlined it.
And it turns out the check for figureState == jobState isn't enough: It would also trigger for trade donkeys.
So check for (active) soldiers directly.

WEIRD: When we call a defender we cancel all attacking soldiers (normal attackers and aggressive defenders) but when a defender is called it is still possible that new aggressive defenders are called and leaving. But it seems this is the original behavior. cc @Spikeone after Discord discussion

[Flow86]

that RANDOM_SHUFFLE2 only changes the copy of the hqPoisitions - not the ones used then in PlaceHQs?

[Flamefire]

Oh, that was supposed to go one method deeper, yes.
Fixed

[Flow86]

I still have one question here. hqPositions_ is now not "in sync" with the positions "used" by PlaceHQs later.

I know its initialized via PlaceObjects and then read here in PlaceHQs. I only ask since its maybe "later" used and creates weirdness since they're not the positions used to place?

[Flamefire]

That method is static and accepts the HQ positions as a parameter, so it doesn't care about the member variable.
If this was an issue it would already have been: We didn't shuffle the member variable before either, only a copy (the parameter passed to the static method)

[Flamefire]

I renamed the method to get HQ positions from the loader to reflect what it actually returns and added a test which would have detected the shuffle issue