[PATCH] Do not assume that buildings can move + AttackMove rallyPoint

[mimo]

When a building is selected and the CTRL key is pressed, the attack-move cursor is displayed when hovering on an ennemy unit. Here is a patch to prevent it.

[sanderd17]

I don't know if it should be removed. Buildings should have some forced attack possibility. I think this requires more discussion.

[historic_bruno]

What if the building is setting its rally point as an attack move order? (I don't know if it does that, but I think it's possible sane behavior)

[mimo]

sanderd17: I agree that we may have an attack possibility, but I doubt we would want a move-attack. The important point in the patch is the "move".

historic_bruno: that's exactly why this patch is needed. Presently, hovering above an ennemy with the CTRL key pressed is interpreted as a move-attack order to the building itself (which will be stopped in GuiInterface because there is no UnitAI component). The patch prevent this, thus allowing a CTRL+hovering an ennemy to be interpreted as a rallyPoint when such a code will be implemented.

[mimo]

I wanted to do the attackMove in rallyPoint in a second patch (after fixing this problem), but as there was some comments about it, here is a completed patch with the AttackMove implemented: if the AttackMove hotkey is pressed while creating the rallyPoint, an AttackMove order is given instead of the default Move order.

[ben]

In 13963:

Prevents buildings from getting attack-move orders and implements attack-move rally points, patch by mimo. Fixes #2171