macros can trash the data stack

[glycerine]

A real issue is that macros can trash the data stack. This should really be fixed. But I
don't know how at the moment. Help wanted.

In v6.0.1 and before there's no issue, because macros were run in separate environments.
But in supplying feature/fixing issue #54, I turned that off.

The two workarounds at the moment are: a) wrap macros is curly braces { } (see #60 and https://github.com/glycerine/zygomys/blob/master/zygo/callgo2_test.go as an example ; or b) use v6.0.1 or before of zygo.

To see an example of the problem, i.e. a red test, simply remove the curly braces from around {(defmap table)} in the callgo2_test.go file, and use the latest head version of zygo, v6.0.5, which does not run macros in separate env.

I was tempted to go back to the macros clone their env first approach for simplicity, but that does not work with this later features added by a user:

• d4521fc fix: perform a tail call on a varargs function would hang forever

When I did so, that test hung again.

[glycerine]

I've just gone back to the safety of running the macros in a cloned environment, as of v6.0.6. Its not worth messing up the Go value interchange for macro features which nobody uses.

The tailcall stuff still works; I was incorrect about that (late night evaluation did not bear out in the morning).