Implement entity tags and commands

[kostmo]

Closes #1631

Design

• Entities have a new property: a Set of textual tags.
• Two new commands are introduced:
  • HasTag checks whether a single entity has a given tag
  • TagMembers allows cycling through all members with a given tag
• TagMembers may be considered more powerful than HasTag, so has its own separate capability (CTagmembers).
• A map is computed at scenario initialization to facilitate TagMembers lookups.
• Tag names are highlighted in yellow in markdown.

Demo

scripts/play.sh -i scenarios/Testing/1631-tags.yaml --autoplay

Other changes

• Incidentally, changed knownEntities from a list to a Set so that Set.member can be used instead of elem.

[byorgey]

This looks great, but I should also say that I am not a huge fan of this style of encoding lists by taking an index as a parameter and returning a pair of the length and the thing at the given index modulo the length. (I know we have already done it for things like the structure command --- I don't care quite as much for commands which are oriented more towards use by system robots.) On the plus side, the scheme is quite simple and first-order. The downsides include (1) it necessitates throwing an exception when the list is empty (or else always return a unit + ... result which would be annoying for different reasons), so you need a net in order to use it when you don't know whether there will be any results at all, and (2) it assumes that the length of the list will remain constant, but could break down in a situation where the results can dynamically change in between calls to the function (e.g. I can easily imagine later wanting to have commands which can dynamically edit the tags of an entity).

Of course the real solution is to implement #154 but that's not happening any time soon. A different solution is to have functions return a list fold, i.e. tagmembers :: text -> (text -> b -> b) -> b -> cmd b. That way it doesn't need to throw an exception for an empty list, and it returns a snapshot of the entire list at a single point in time, so we won't get inconsistent results if the list changes later. However, this approach has its own downsides, in particular it is more involved to implement and probably requires adding some new specialized CESK machine frames.

Definitely open to other ideas.