Allow NPCs to toggle on power armor (and other things) during combat

[NEricN]

Summary

Features "Allow NPCs to toggle on power armor (and other tagged items) during combat"

Purpose of change

Currently, if NPCs are given items such as power armor, they require the player character to activate them for them, and will not deactivate them until batteries are drained or the PC deactivates it for them. This adds extra micromanagement for NPC squads. This change will allow NPCs to toggle power armor themselves when in combat, and toggle them off when outside of combat. Mods can also make use of the new COMBAT_TOGGLEABLE tag to make NPCs aware that they can toggle them.

Describe the solution

1. A new flag is added, COMBAT_TOGGLEABLE. This allows any item with a "transform" action to be tagged, so NPCs can be aware of them.
2. When entering combat in method_of_attack, this checks for all items the NPC is wearing that contains the tag COMBAT_TOGGLEABLE. This then checks to see if the item can be transformed, and if the item uses UPS, then whether or not the user has sufficient UPS charge. If all checks pass, then it activates the item. This follows the same entry point where defensive CBMs are activated, in anticipation of combat.
3. When the NPC no longer detects any present danger, it deactivates all active items that are transformable and have the tag COMBAT_TOGGLEABLE. This point is at the same place where combat CBMs are disabled.

With regards to JSON, this only adds the tag to power armor. Other items I originally planned, such as the combat chainsaw, use their own special iuse functions. However, mods can start making use of the tag.

Describe alternatives you've considered

• Add an option to discuss how NPCs should use combat items, similar to CBMs. Unlike CBMs, however, you can easily remove items from NPCs, so if you don't want your follower using an item, then it should be given to them uncharged or not at all. This would add a lot of pipelining of options for little gain.
• Hardcode power armors. This would make it harder to add new items, especially for mods. It would also restrict what other "combat" items NPCs can toggle on.
• Convert existing weapons. Currently, weapons like the combat chainsaw actually follow their own custom iuse. Looking at it, I think it could be converted into a more general transform, but I would say that's out of the scope of this PR.

Testing

• Added new unit tests to cover most cases
• Ran existing unit tests, only failing ones are those already failing at HEAD
• Manually tested by:
  1. Spawning an NPC.
  2. Setting the NPC trust level to 200.
  3. Asking NPC to follow.
  4. Give NPC power armor.
  5. Give NPC UPS with battery.
  6. Trade, check that power armor is off.
  7. Spawn enemy.
  8. Wait one or two ticks.
  9. Trade with NPC, check that power armor is on.
  10. Observe that the message prints out that the NPC has turned on the power armor.
  11. Kill enemy.
  12. Trade with NPC, observe that power armor is off.
  13. Observe that the message prints out that the NPC has turned off the pwoer armor.

Additional context

[dseguin]

This is a cool feature! My only question is should there should be an activate_on_danger function that calls all the other activate functions, like how npc::cleanup_on_no_danger() calls all deactivate functions? (Although it doesn't matter too much)

[NEricN]

Added a prepare_for_combat method. The cleanup_on_no_danger runs when all dangers are passed (no explosives, no enemies, etc), while prepare_for_combat only runs when the NPC is about to attack, instead of for any danger, so I specified it to be only for combat.

The previous build mentions that it failed the C++ build, but I see that the link shows a success. Is this a known issue?

[NEricN]

I've resolved merge conflicts, so this should be ready. I see that the Windows build has failed, but looking over the past runs, there seems to be failures even with pure json changes, and I've seen PRs get merged with that failing. The error is also an ambiguous "internal" error. Please let me know if that will be a blocker - the cross compile builds seem fine.