* "Uncooperative cards" is now a warning.
* Cards and actions get "Then" invoked before the card processor considers erroring out.
* Terminal UI: Errors and warnings from actions are displayed during the response; they're not only added to the temporary messages now.
Only cards can block other cards or actions from being used due to urgency, so only display the `[URGENT!]` header for cards. Debug actions can't be blocked, so skip the "urgency conflict" check for those.
StatLiteral: just emit a stat in the obvious way. Plus helper functions.
Can also identify stats via struct tags, no more Stored type!
Can also identify stat methods via name (with compatible types).
Fixes some off-by-one errors. A 1-indexed UI in a 0-indexed language is always going to be prone to those and I will no doubt find more when I have enough of a test program to experiment with...
Make it possible for a card to display an option but not actually allow it to be selected. It's up to the UI layer to decide how to display options that are not enabled. The option text should probably contiain a note on why the option cannot be selected...
Stripping cards from the Hand will also be useful, so I pulled the logic of Strip out into arrayutil (more efficiently, too) and rewrote deck.Strip to use it.
Given a function that identifies cards to remove, remove them from the deck. This can be used to find and strip out cards that are only conditionally appropriate (and aren't appropriate anymore).
A card can be shuffled into the deck because of a certain condition, and then that condition could cease to apply. If the card should not be presented to the player, it gets one last chance to hide.
There is currently no direct mechanism for making a card _already in the hand_ disappear if it is not relevant, although there are various ways to implement a Rule to do this.
This simulation engine is intended for people who are interested in game design, not computer programming -- the engine wants to do all the engine stuff so the simulation can be implemented with less familiarity with the language. Generics, however, are not widely regarded as a "new programmer" thing -- even though they're surprisingly familiar, in the end (slice-of-T, map-from-K-to-V). So a long comment explaining a bit about what's going on seems warranted.
