feat(core): Support moves that don’t contribute to numMoves

[delucis]

This implements a long-form move syntax that prevents a move from incrementing numMoves and by extension triggering move limits. It would close #644.

This is a slightly naïve way of implementing this noLimit feature because as a consequence we completely lose track of those moves in the move counts. In theory we could track numMoves and limitNumMoves separately and trigger move limits using the latter, but it would make state and logic more complex. Let me know if you think it’s acceptable as is or if we should implement the more robust version.

[nicolodavis]

Looks good!

[tibo1902]

Hi,

Would it be possible to modify this functionality as follows:

add a moveCost property with a default value of 1. If it's set to 0, it will work as noLimit: true, with the possibility of setting higher costs for certain moves.