Add a feature that enables string output for debugging purposes

[konnov]

As noted by @cason, it would be nice to have string manipulation to produce debugging output:

Example: to debug a model I have a "lastAction" string field keeping track of... what its name says. I would really like to be able to do something like that:

state.with("lastAction", "addPeer ".concat(peer.ID))

where peer.ID in this case is already a string (to be honest, is a type alias to a string).

In general we would like to avoid hard-to-verify string manipulation expressions. Perhaps, we could introduce a special IO type that allows for string output and recognition, while not allowing it to be mixed in the specification itself.

This is also related to #779.

[shonfeder]

What about a way to define "views" or "representations" that determine how a datatype is displayed, but are not available as input back into the model.

This is similar to the idea of an IO type for debugging, but I think is a bit more general in the sense that we could use these also for rendering the output in our pretty-printed traces, but more specific in that we could say each defined type may have at most 1 defined view.

This kind of functionality could exposed via something like:

type lastAction = {
  name: string, 
  id: int
} with 
  repr(a: lastAction) = "${a.name}${a.id}"

We would register the string interpolation recipe in a dictionary of functions, associating each type with itsrepr function (defaulting to its current representation). This could give users the ability to determine type-directed representation in all our pretty printed outputs. But we could avoid exposing the repr operators on the spec, so they cannot effect the computational complexity of the model.