Use a state for Attr, drop context.state, use setState and getStates instead

[jimmyhchan]

i'm closing #137 in favor of this.

I've moved the logic around states into

1. a visitorApi accessible from this
2. a Stack in the build instructions that reads from the states set on the node and keeps track of the stack of states.

Questions/TBD:

• instead of attrIdx on the framestack, we could have HTML_ATTRIBUTE on the stateStack instead.

[jimmyhchan]

Do not merge yet.

<textarea>{#foo}<div>bar</div>{/foo}</textarea> currently fails. (Need to add a test for this.)

The current framestack for tornado_body's only knows that it should reset the elements and placeholder stacks (when it does a new tornado stack) but it doesn't know about the escapable_raw (or any other state)

In order to remove context.state (if we choose to keep the generateJS code the same) we must continue to support the logic that bodys will reset state. It's a bit strange to have the same logic in the framestack and in state but IMO they serve two different purposes.

[jimmyhchan]

actually, this was an issue even before my code refactor. The generateJS step is not setup to have a tornado body in a textarea

[smfoote]

Should we merge this, then? And create a new issue?

[jimmyhchan]

i think #139 may make more sense if we get more states in the future.

[jimmyhchan]

closing in favor of #139