When the bell is rung, units ejected from a destroyed building should garrison in another

[wraitii]

This is a little "bug" I found when fixing something for the unitMotion rewrite. If you ring the bell, then destroy a building units were garrisoned in, then those units stand there idle. They should instead try to find another place to go in. I believe the fault lies in GarrisonHolder, which calls "OrderWalkToRallypoint" when ejecting an entity instead of relying on the "leave" handler of UnitAI. If we used the leave handler of UnitAI, we could handle both cases more elegantly.

[Imarok]

Refs #4185

[elexis]

Backlogging due to lack of progress

[Imarok]

Move tickets to Simulation as UI & Simulation got some sub components.

[Krinkle]

Should this apply to any unit rejected from a destroyed building, or only units that garrisoned themselves by a rung bell?

The latter might be preferred so that players retain greater control, and so as to avoid removing too many decisions from the players. E.g. when a building you forgot about gets destroyed, it might seem unfair if the units garrisoned inside automatically garrison elsewhere. Seems like something the player should re-ring a bell for to happen.

If we do go the route of doing it always automatically, we may need to decide what to do in other cases of idle units. E.g. units that were newly trained, units that were explicitly ungarrisoned to do something and then became idle (e.g. collect a resource, or fight). Should they automatically garrison themselves as well upon completing their last queued task, or after being newly trained, or after explicitly being ungarrisoned (the latter would be a bug).