Add system changes to facilitate Whirling Swipe

[CarlosFdez]

Because whirling swipe isn't in pf2e, and each change in isolation doesn't look relevant until you put them all together, I did it all in one. Let me know if any look fine to split into a new PR.

1. Include targetItem as a resolvable for item alterations, so that item alterations can refer to sibling properties
2. phase is now supported for item alterations. This allows traits to be set after CreatureSize REs occur. What phases are allowed depend on the property. Delayed properties (persistent damage dc) were refactored to use the phase property.
3. WeaponPF2e#reach to mirror MeleePF2e#reach, so that we can actually access it within the item alteration. getReach() now delegates work to the getters. I wouldn't mind a reach.base and reach.attack fields to mirror what we do in the actor's reach data though, either as a getter or as system data, but then we will have to change melee.reach to correspond.

Afterwards, this implements whirling swipe:

{
  "domain": "all",
  "key": "RollOption",
  "option": "whirling-swipe",
  "toggleable": true
}

{
  "key": "ItemAlteration",
  "itemType": "weapon",
  "property": "traits",
  "mode": "add",
  "phase": "beforeDerived",
  "value": {
    "trait": "area-burst",
    "annotation": "max(5, @targetItem.reach)"
  },
  "predicate": [
    "item:melee",
    "item:hands-held:2",
    "whirling-swipe"
  ]
}

[CarlosFdez]

Going to try to see how difficult it'll be to limit phase by property type. Drafted until then.

[CarlosFdez]

Phase is now validated based on the property. Persistent Damage DC only allows afterDerived (which it did before, but it used a different mechanism). Traits allows either applyAEs or beforeDerived.

[CarlosFdez]

I think for item alteration we can look into value allowing a base trait and value (config?) pair, and allowing value to be resolvable. That would remove the need for being able to resolve math expressions inside {} blocks and cut down on this PR quite a bit.

[CarlosFdez]

This has been updated to make use of the new annotation property in the traits item alteration, allowing me to remove formula support within curly braces. Unless we move when creature size occurs, we still need the phase property.

[stwlam]

Multiple?

[CarlosFdez]

These are the supported ones, not the resolved one. I realize now that its ambiguous, so I renamed it to supportedPhases.

[stwlam]

Maybe it should be static, then?

[CarlosFdez]

Its the supported ones for that specific instance, which handles a specific property, not for all handlers. All item alteration properties use the same class but different class instances.

For example, traits in this PR has supported phases ["applyAEs", "beforeDerived"],. Recovery dc alterations has ["afterDerived"],. The other alterations use the default, which is ["applyAEs"]

[stwlam]

wack, but ok