[tclquadcode] Data motion to/from callframes

[Kevin K. <kev...@gm...>]

Thanks to Donal's clarifications of the status of callframe management,
I've managed to get things to where all the demos pass, except for
four cases that throw errors. These appear to return subtly different
error dictionaries.

Accordingly, I've merged the 'kbk-callframe-motion' branch into
'dkf-callframe-impl', and closed the former branch. This merge also
picks up the fixes from 'kbk-callframe-fixes' that repaired the
endless loop on the 'mrtest' tests.

Next steps will have to be:

(1) If an 'invoke' is known not to affect the callframe at all
    (many Core commands; all compiled procs until we understand
    [upvar]), then change the sequence from

        invoke intermediateStruct callframeIn command arg arg...
        extractResult varOut intermediateStruct
        extractCallframe callframeOut intermediateStruct
        ...
    to

        invoke varOut Nothing command arg arg ...
...
        (all uses of callframeOut replaced by callframeIn)

(2) If, after this step, it is discovered that all 'return' and
    'returnException' operations use the callframe pushed by the
    'entry' operation. then it's unnecessary to push a callframe
    at all.  Change the entry from

        entry callframeOut {literal {list of variable names}}

    to just

        entry {} Nothing

    and replace all the uses of the callframe with Nothing.


This means that the following operations must all be prepared to
accept Nothing in place of a callframe as an input parameter:

    entry - indicates that no callframe need be pushed
    invoke - indicates that the target command does not use the
             callframe. The type of the result is the return type
    of the target command, without a result callframe.
    result - The interpreter result should be the same irrespective
             of whether a callframe is in use.
    return - indicates that no callframe need be destroyed
    returnCode - The return code in the interpreter should be the same
                 irrespective of whether a callframe is in use.
    returnException - indicates that no callframe need be destroyed
    returnOptions - The options dictionary in the interpreter should
                    be the same irrespective of whether a callframe is
   in use.

It would be better to test for a zero data type code (or for NOTHING
as the text equivalent) rather than to look for the literal 'Nothing'.
If this introduces difficulties, it would be possible to introduce a
new opcode for any of these cases.

Let me know what would be easiest, and I'll code accordingly.

Once this is accomplished, the tests should buy back all their former
performance, and we'll have added callframe-dependent operations such
as [scan] and [regexp].