[Refactor][Move] Add options param interface for MoveEffectAttr

[innerthunder]

What are the changes the user will see?

N/A

Why am I making these changes?

At the time of writing this, MoveEffectAttr has five optional fields:

/**
 * Defines when this effect should trigger in the move's effect order
 * @see {@linkcode phases.MoveEffectPhase.start}
 */
trigger?: MoveEffectTrigger;
/** Should this effect only apply on the first hit? */
firstHitOnly?: boolean;
/** Should this effect only apply on the last hit? */
lastHitOnly?: boolean;
/** Should this effect only apply on the first target hit? */
firstTargetOnly?: boolean;
/** Overrides the secondary effect chance for this attr if set. */
effectChanceOverride?: number;

These fields help control when the attribute's effect triggers and what chance the effect has of triggering, but in general these fields are used very sparsely throughout the move code to resolve specific edge cases.

At the same time, we currently set these fields with a long sequence of constructor params:

constructor(selfTarget?: boolean, trigger?: MoveEffectTrigger, firstHitOnly: boolean = false, lastHitOnly: boolean = false, firstTargetOnly: boolean = false, effectChanceOverride?: number) {
  // ...
}

This can cause a lot of issues in terms of readability. For example, Triple Arrows has an attribute for its chance to drop the target's Defense that requires effectChanceOverride to set its chance of applying to 50%. Despite only requiring one of the optional parameters, this attribute needs to be constructed like this in allMoves:

.attr(StatStageChangeAttr, [ Stat.DEF ], -1, undefined, undefined, undefined, undefined, undefined, undefined, undefined, 50)

Of course, this also extends beyond the existing options. With potential additions from future implementations and the move scoring flags planned for the AI Rework, the code's readability is only going to get worse if the same structure is kept.

What are the changes from a developer perspective?

data/move:

• Added interfaces (MoveEffectOptions and StatStageChangeAttrOptions) to store optional parameters for MoveEffectAttrs and StatStageChangeAttrs, respectively.
• MoveEffectAttr now stores all of these parameters in a single field:

  protected options?: MoveEffectOptions;

  The attribute's constructor params were also changed to reflect this, and similar structural changes were made to StatStageChangeAttr.
• New get functions allow optional parameters to be accessed in the same way as before (albeit readonly) and with the same default values.
• SecretPowerAttr has been changed to reflect effectChanceOverride now being readonly. The effect chance roll is now done within attributes invoked internally within the apply function.

The End Result: Attributes e.g. Triple Arrows' Defense drop can be initialized as follows:

.attr(StatStageChangeAttr, [ Stat.DEF ], -1, false, { effectChanceOverride: 50 })

Screenshots/Videos

N/A

How to test the changes?

npm run test secret_power (1 test updated)
npm run test for general coverage of attributes with changed syntax

Checklist

• I'm using beta as my base branch
• There is no overlap with another PR?
• The PR is self-contained and cannot be split into smaller PRs?
• Have I provided a clear explanation of the changes?
• Have I considered writing automated tests for the issue?
• If I have text, did I make it translatable and add a key in the English locale file(s)?
• Have I tested the changes (manually)?
  • Are all unit tests still passing? (npm run test)
• [n/a] Are the changes visual?
  • [n/a] Have I provided screenshots/videos of the changes?

[DayKev]

Maybe moveEffectTrigger should also be moved into the options interface, since it's set to undefined fairly often still in these declarations.