Max constant value limit

[Engezerstorung]

Introduce a constant max value cap as a third argument during const_def, throw an error in const if const_value > const_max.

Useful for situation where $FF is reserved for terminator use or otherwise, or when there is an engine limitation on available IDs like for tilesets.

For now i have set it as a third argument and with a default maximum of $FFFF as to have it be backward compatible with current data structure.
Idealy I imagine it as a second argument and with a maximum of $FF. The reasoning that most constant are often limited to 8 bits and there is more often constants where $FF is excluded than there is a difference in "step" for the next constant.

[Rangi42]

Drafted for now because I'm sure other constant series can/should have explicit max values. And the map constants should have const_def 0, 1, LAST_MAP - 1, without their now-redundant ASSERT.

[Engezerstorung]

for the map limit -1 is also used as terminator for IsInArray searching function, outside of LAST_MAP considerations

[Engezerstorung]

the macro could also be improved with something like

but i dont know how to properly define a string as a variable in a macro
(could also initialize the variable as NONE during const_def)

[Rangi42]

Define strings with EQUS.

Also leaving this as a draft because after it's reviewed and ready, I'll want to open a similar PR for pokecrystal and make sure they're in sync before merge.

[Engezerstorung]

Changed terminology "max" to "limit" :
By default :

• when increment is positive and starting value is >=0 then limit = $FF.
• when increment is negative and starting value is <=0 then limit = -$FF.
• otherwise limit = all values around the byte (exemple : increment of -1 starting from 2, limit back to 3).

Other than set values/constants, can use WORD, NYBBLE and BIT as a third argument to change the "default format" from $FF to $FFFF, $F and $7 respectively.

Error message now tell :

• what is the limit value and if it cant be smaller/bigger than.
• what is the constant string and value of the attempted definition.
• what was the constant string and value of the last valid definition for the list (if it fail while defining the first constant of the list, it say so).

Added some constants for limit:
FF_TERMINATED_CONST for constants lists that are subjected to have the $FF value used as a searching terminator (like for IsInArray). Constant added to the lists that are used with IsInArray.
Added WORD limit for events constants list.
Added engine limit to Tilesets.
Added limits for pokemon and trainers due to the shared nature of their IDs.

WIP:
Find more lists limited by an $FF terminator search outside of IsInArray usage or limited by engine value manipulations.
(Questioning if i should move OPP_ID_OFFSET definition here, but it doesnt feel right.)

Welcoming opinions.

[Engezerstorung]

Added more $FF terminated searchable constants
Added more miscellaneous limits

Keep the update commit separated for clarity in the draft, will most liequelly squash for actual commit unless told otherwise.

[Rangi42]

@Engezerstorung I hope you don't mind, but I ended up taking a rather different approach to your idea in https://github.com/Rangi42/pokered/tree/const-max.

• Simpler assertion failure messages (no need for manipulating EQUS)
• Use macros like bit_const_def instead of constants like const_def 0, 1, BIT (hides the details, no need for a new constants file)
• Comment on unusual limitations (sprite constants and tileset constants)

Personally I think that verifying the unusual limitations is the biggest benefit of your idea, since the fundamental byte- and word-based limits tend to show up anyway from db or dw overflow errors. So it would be helpful to look around and see if any other constant series have such limits. (I'm less familiar with the common issues people encounter in #pokered, maybe there are some other well-known limits?)

[Engezerstorung]

Make const_def more robust for edge cases.
NYBBLE and BIT defined constants are forced to be between 0 and $F or $7 respectively.
Defined constants values are masked as to not be actually bigger than their intended "format" when negative. (if CONSTANT -1 is intended to be $FF, then avoid the issue where ld bc, CONSTANT woud result in bc = $FFFF).

Fixed const_next, it previously wouldnt have been behaving properly in some situations.
Exemple : const_value > 0 but incrementation negative and \1 < const_value would have resulted in a fail situation when it shouldnt have.

[Engezerstorung]

Took inspiration of macros bit_const_def & co from rangi42 pr #561 with a different approach. They dont define a limit, but the "format" expected for the constant values.

[Engezerstorung]

Added limit verification to shift_const, macro also now define BIT_\1 constant for bit order value.