More advantage mode coverage

[krbz999]

A continuation of #4838.

Modes:

• Add: Adds one source of advantage (1) or disadvantage (-1).
• Upgrade: Makes it impossible to have disadvantage (0, 1).
• Downgrade: Makes it impossible to have advantage (-1, 0).
• Multiply: Does nothing.
• Override: Forces one advantage mode regardless of other sources, downgrade, or upgrades.
• Custom: is custom.

[roth-michael]

I don't know how I feel about what I'm about to suggest, but might it make sense to do a ui warn notification if someone uses upgrade/downgrade/multiply/override for the time being, informing them that Add is the only functional change mode currently? On the one hand, I kind of hate that. On the other, it would definitely ensure that it gets fixed since it'd pop up every time data prep happens.
Probably not worth it, but I dunno. If nothing else maybe a console.warn

[Fyorl]

The static model schemas do make accomplishing this a bit more difficult. We do have an instance available to us though, if we don't want to do everything in static scope with maps like this. Active Effects are already a part of data preparation, so I don't think there's any conceptual issue with us applying some additional prepared data that isn't the exact property that was targeted.

For example, where we wanted an instance-level advantage property, we could store it on the model instance itself, as a sibling to the targeted property.

const roll = foundry.utils.getProperty(model, change.key.substring(0, change.key.lastIndexOf(".")));
roll.advantage++;

The property will be removed/reset when the Actor is re-prepared, like all derived properties. This does rely somewhat on a predictable data structure though.

We could also put these maps on the model instead, and track them via fieldPath in a similar way to this PR. Something like actor.system.advantages, similar to the original proposal in #809.

I think I prefer keeping the data closer to the targeted field though, which allows the PR to function mostly as it did before.

I did take a look at your original commit in this PR, and the logic looks good to me. So we would want to integrate whichever of the above proposals we settle on with your original logic. Sorry that I was not clearer in my comments on your other PR.

Also, apologies if this is feeling like too much whiplash. I think I have enough that I could make any final changes myself now if you'd prefer. Any thoughts you have on the above are welcome though.

[krbz999]

I'll force a commit and we'll see what comes of it.