scope -> virtual_machine + frames

[kurtbrose]

there are a few things pushing us to move from a scope to a virtual machine:

1 - performance

a - sticking target, spec, UP, MODE etc on the scope is expensive

b - looking up scope[glom] is expensive

2 - correctness / maintainability

a - glom naturally has an "execution stack" but this isn't modeled properly

b - debugging / introspection (e.g. _unpack_stack(), format_target_spec_trace()) would more naturally hang off a virtual machine object

[kurtbrose]

having a real GlomMachine and GlomFrame types would also give a natural place to hang caches off of -- e.g. to save partial results or recompilation (see ACC_TREE and CUR_AGG in grouping.py -- maybe a cleaner way to handle those)

another benefit is familiarity and consistency with other language implementations

also, a GlomMachine would be a natural place to do various JIT-ing activities (e.g. memoization of certain expressions) in the future

[kurtbrose]

also, a GlomMachine is an easier-to-work-with object to attach to an exception than just a bare ChainMap of scopes

I think just using a plain chain-map was the right choice two years ago -- it deferred a bunch of choices that there wasn't enough information to make correctly; (or at least, without prior experience writing language runtimes)

now, there's enough usage and different types of specs that the shape of these objects is clearer