Extend bulk ItemAlteration to allow for further modes

[Cerapter]

This is a reworked / extended version of PR #18126.

This PR adds or changes the following ItemAlterations:

• bulk is changed to be able to accept most of the modes. It's add and subtract that's especially noteworthy -- SF2's Soldier can subtract from an armour's Bulk, and PF2 has a few things that add to an item's bulk, like Eyecatcher, Subtle Armour, and the Fortification rune.
• level has been added to change an item's level. This will prove more useful as part of GrantItem, I believe, especially for effects that grant other effects. I personally ran into a use case with the Wand of Hawthorn, where I wanted to make an effect that grant Oaken Resilience at a given rank, and adds a note about the thorns on being struck with an unarmed attack.
• flags would just be useful for homebrewing and there is no real justification for it from the system's standpoint (because the system is the system, and the system can just implement shit in code that it needs). The format for the value here is that it must be an object, for example:

  "value": {
    "a": 1,
    "b": {
      "c": 2,
      "d": "whatever"
    }

  With a mode of override, this would make the ItemAlteration add these flags to the item(s), unless of course the types of the values mismatch (for example, if "a" = "test", it couldn't be overwritten by a number). The default location of these flags is flags.pf2e. With a mode of add, and the b.d removed, we could add 1 to a, and 2 to b.c at the same time.

Ultimately, I separate the three into their own commits, so if one is not accepted, so be it, I can revert it.

[stwlam]

I think we just need the bulk one out of this. Effect level is propagated via different workflows, and flags just aren't going to happen with that RE.

[stwlam]

We'll an additional check here to ensure the resulting value is valid.

[Cerapter]

I already round the resulting value to 1/10ths, but I can add a check for it to be nonnegative, at least.

[stwlam]

0.1 (L) is also the only valid non-integer value since Light bulk isn't a countable unit of measurement.

[Cerapter]

Technically correct, in practice, the system can actually handle values like "9L" or "3; 4L".

[stwlam]

:)