Fix bombers not keeping track of attack ground tries (FAForever#6277)

<!-- General useful tooling:
- [ScreenToGif](https://www.screentogif.com/): Free, open source screen
recorder that can export to MP4. If the changes are visual, these can
help you tell us exactly what the changes imply!
-->
<!-- Feel free to remove unused parts of this template. -->

## Description of the proposed changes
<!-- A clear and concise description (or visuals) of what the changes
imply. -->
<!-- If it closes an issue, make sure to link the issue by using
"(Closes/Fixes/Resolves) #(Issue Number)" in your pull request. -->
Stops bomb dropping weapons from resetting their target mid-bombing run,
since that caused them to reset their `AttackGroundTries` counter, which
meant they would never move on to the groundfire target.

## Testing done on the proposed changes
<!-- List all relevant testing that you've done to confirm the changes
work. -->
Give a bomber two groundfire orders, it should switch to the next order
after attacking 3 times.
Note: It won't drop a bomb on the third pass, but this is due to a
separate bug and does not impact what is being fixed here.

## Additional context
<!-- Add any other context about the pull request here. -->
Cherry pick from FAForever#6166.

## Checklist
- [x] Changes are annotated, including comments where useful
- [x] Changes are documented in the changelog for the next game version

changelog/snippets/fix.6277.md

@@ -0,0 +1 @@
+- (#6277) Fix bombers never switching ground attack targets. They now switch to the next ground attack target after 3 tries (the default number).

engine/Core/Blueprints/WeaponBlueprint.lua

@@ -39,6 +39,8 @@
 ---@field ArtilleryShieldBlocks? boolean
 --- information about the audio files used by the weapon
 ---@field Audio WeaponBlueprintAudio
+--- How many times the engine calls OnFire for the weapon when attacking ground before moving on to the next ground attack order. Defaults to 3
+---@field AttackGroundTries? number
 --- if the unit has no issued commands and has a weapon that has `AutoInitiateAttackCommand` set,
 --- then if it finds a suitable target it will issue an attack command to go after the target
 ---@field AutoInitiateAttackCommand? boolean
@@ -205,8 +207,8 @@
 --- if `NeedProp` is true then whenever the unit aquires a new target and is ready to attack it, it
 --- will first run the `OnGotTarget` script on the weapon
 ---@field NeedPrep? boolean
---- currently just sets `AlwaysRecheckTarget = false` so that bombers don't retarget halfway through
---- a bombing run
+--- sets `AlwaysRecheckTarget = false` and prevents automatic target resetting
+--- so that bombers don't retarget halfway through a bombing run
 ---@field NeedToComputeBombDrop? boolean
 --- if the unit is set as "busy" while the weapon charges
 ---@field NotExclusive? boolean

engine/Sim/UnitWeapon.lua

@@ -122,7 +122,7 @@ end
 function UnitWeapon:PlaySound(params)
 end
 
----
+--- Force the weapon to recheck its targets. Also resets the counter for AttackGroundTries
 function UnitWeapon:ResetTarget()
 end
 

lua/sim/weapons/DefaultProjectileWeapon.lua

@@ -884,7 +884,8 @@ DefaultProjectileWeapon = ClassWeapon(Weapon) {
                 ChangeState(self, self.RackSalvoFiringState)
             end
 
-            if not (IsDestroyed(unit) or IsDestroyed(self)) then
+            -- Bombers should not have their targets reset since they take a large path much longer than their reload time.
+            if not (IsDestroyed(unit) or IsDestroyed(self)) and not bp.NeedToComputeBombDrop then
                 if bp.TargetResetWhenReady then
 
                     -- attempts to fix weapons that intercept projectiles to being stuck on a projectile while reloading, preventing
@@ -896,11 +897,11 @@ DefaultProjectileWeapon = ClassWeapon(Weapon) {
                     self:ResetTarget()
                 else
 
-                    -- attempts to fix units being stuck on targets that are outside their current attack radius, but inside
-                    -- the tracking radius. This happens when the unit is trying to fire, but it is never actually firing and
+                    -- attempts to fix weapons being stuck on targets that are outside their current attack radius, but inside
+                    -- the tracking radius. This happens when the weapon acquires a target, but never actually fires and
                     -- therefore the thread of this state is not destroyed
 
-                    -- wait reload time + 2 seconds, then force the weapon to recheck its target
+                    -- wait reload time + 3 seconds, then force the weapon to recheck its target
                     WaitSeconds((1 / self.Blueprint.RateOfFire) + 3)
                     self:ResetTarget()
                 end