Scope bug and generators

This PR: 
  - Fixes the implementation of generators by giving each frame its own data stack, not having one data stack for the VM (thanks to @rntz for pairing on this).  I think this is consistent with the implementation of CPython. See, e.g., [this blog post](http://tech.blog.aknin.name/2010/07/22/pythons-innards-interpreter-stacks/): 

    >Finally, inside each frame object in the call stack there’s a reference to two frame-specific stacks ... the value stack and the block stack."

  - Exposes and fixes a bug around nested scoping that allowed inner function scopes to clobber outer function scopes if they had identically-named variables (this was part of the problem with generators, which set up a local variable named ".0").  The fix is to not pass through the local variables from one frame to another.  I think this solution is true to the implementation of CPython and not just an ugly hack.
  - Exposes problems with class inheritance - I think this was only ever working because of the bad scoping bug above.  I've added a test of dynamic attribute lookup that shows our old implementation wasn't right.  This PR doesn't fix the class inheritance problems in Python 2, but I have spent a lot of time reading through object.c, typeobject.c, and classobject.c, so maybe I'll make some headway on that eventually.
  - Adds "if PY2" around the object and class implementation to make clear that we're not using them in Python 3.  (We're not putting 'if PY2' and 'if PY3' around every bytecode or function that's specific to one or the other, but I think it's worth it here - I didn't realize until a few days ago that we're falling back to the builtin objects and classes in Python 3.)