Refactor Display to make it simpler/more robust

[byorgey]

There are several things about Display that seem a bit awkward. It definitely feels like there is a better design hiding in there but we haven't been able to figure out what it is yet.

I wonder if that is a good responsibility division - perhaps there is a better abstraction/wrapper for displayable things that have orientation, and their drawing depends on it. 🤔
I am hoping things would get simpler if robots (or later other entities) set the drawn character from their direction map when they are themselves changing their orientation, keeping the source of truth in the robot (or entity).
Caching seems like overengineering to me - I am worried it would just cause bugs.

Originally posted by @xsebek in #556 (comment)

[xsebek]

Funny enough based on coverage, we do not use this functionality even for robots so far:

For entities, it makes little sense to have a direction and direction map, since you can not turn them or get their direction or appearance string programmatically. Maybe that could change with #455, but it seems impractical to use direction map.

[byorgey]

I'm not sure what you mean. That is just the code for handling the "appear" command. Robots certainly do use the functionality of a direction map. That coverage report just means we never test the 5-character variant of the appear command.

[xsebek]

What I meant is that we do not currently change the map after the robots are created. So most of the robots just share one map and a few robots could do with singleton maps.

But that could maybe change with a scenario that has shapeshifting robots.

It seems to me that it is a bit hard to use this feature since we do not use it too much.
So it would be even harder to use direction map instead of single character for entities.

[byorgey]

Thinking about this a bit more, perhaps a cleaner solution is to have two types:

1. EntityDisplay, which is the current type minus the cached orientation.
2. Display, which would contain simply a character, attribute, priority, and boolean for invisibility.

The point is that each robot or entity could store an EntityDisplay containing all the information about how it should be drawn in various circumstances. When we go to concretely draw a frame, we generate a Display value for each thing to be drawn (possibly by consulting its current orientation, etc.); the Display values for a single cell are then combined according to the Semigroup instance.

While we're at it, perhaps Display could also optionally contain a background color, and we could generate one for each terrain as well. Then we could truly decide how to render each cell by composing a bunch of Display values.