Improve handling of return values

[istathar]

Refine our handling of return values.

We add a Transcript driver to allow us to observe the values being generated during a run and the decisions being made about the results of each step. This allowed us to debug a number of gnarly deficiencies relating to how those values were assigned. This is accessed by passing --output=native to the _technique run` command.

If an exec() function in a step fails that now results in a Fail judgement for the step. To facilitate that we (internally) use an outcome Outcome::Throw to signify a failure more that needs to propagate up, distinct from Outcome::Fail which simply records the failure of that step and then allows the procedure to continue.

During translation steps are now marked as being computable or not, that is, if a step is pure prose then it can be Done does not convey a Value. On the other hand, if expressions are present then the value of the final expression does become the value of the step recorded in its result.

A significant correctness arose from multiple code blocks in the paragraph body of a step. If an inline code expression spanned more than one lines, or if an expression apperaed on a second line it was not interpreted as being a part of that paragraph. This led to other confusion: the control structures do create scopes beneath them and conventionally are to be formatted onto their own lines. This branch fixes the ambiguities around that behaviour.

Finally we have resolved the significant weakness around resuming runs where values had already been entered by the user. This involved recording them in the PFFTT file under new state verb Input.

[istathar]

This further evolved into a change to the PFFTT format, adding Input lines to record parameter values supplied to procedures when they are invoked.

• Define PFFTT for use in running Technique documents specification#9