Player choices with loops

[nsensfel]

There should be a way to generate player choices using loops. It's pretty important for stuff like inventory management, enemy selection, and plenty of other stuff.

This presents two challenges:

• The player_choice instruction currently only allows conditionals, foreach, and actual player choices. The set_value instruction would need to also be added for loops to work properly.
• The instructions resulting from a choice being selected are only evaluated after the choice has been made. Thus, when a loop variable is used in the label, there is no issue, but if it is used within the instruction list, it gets the value it ended up with after the loop completed. Even the current foreach suffers from this issue. This simply won't do.

[nsensfel]

19d1cd9 resolves the second part, but at a cost: the new strategy is that once the choice has been made, the whole player_choice is re-executed while bypassing the labels until the choice corresponding to the one made by the user is reached, at which point the associated code is executed. It works as long as re-executing the player_choice generates the same choices. Thus, for this to work properly, any conditional or loop using rand would have to be forbidden: the random values would then have to be computed prior to the player_choice construct. It's a bit annoying, but definitely much better than not being able to use loops. A new Wyrd computation had to be added, which is not great in itself, but it also simplified two Wyrd instructions (choice numbers are used outside of Wyrd instead of code lines, which simplifies thing for the user).

Making rand be deterministic on that second pass might be doable in pure Wyrd, with some register serving as a flag to indicate that rand results should be stored in a list, and another indicating that rand results should be taken from there instead. As much of a hack as it looks like, this is likely still an easier solution than somehow storing the right values for each variable that the code would otherwise need to access.

[nsensfel]

d68040d resolves the issue of rand, following the strategy from the previous message.

[nsensfel]

Also implemented a for equivalent for choices. It's a bit tricky to use compared to the usual for:

• Variables must already have been declared (same as with the standard for).
• Syntax is that of let for the "pre" and "post" operation: ( (VAR_NAME VAR_VAL) ... )
• Variables set in the "post" operations must have been defined in either a parent or the current 'for' "pre" operations for this specific player_choice construct.