Move globals out of the MVP

[lukewagner]

Based on a lot of discussion in #154, I'm proposing we remove globals from the MVP. This PR also discusses the different things we want post-MVP: immutable global pointers for dynamic linking, mutable thread-local variables for threads, and a new future feature for real mutable global variables that captures the use cases.

[kripken]

lgtm.

[jfbastien]

Langauge fail.

[jfbastien]

Nowadays it's Fortran. No more yelling.

[lukewagner]

Done

[jfbastien]

lgtm, but it would be good to leave this open until early next week, so @titzer and others who are supposed to be on vacation can take a look :-)

[kg]

If we do this we should consider adding a way to explicitly set a symbol's numeric value. That will let us assign the heap locations of global state names in our test cases (and make it possible to round-trip them in a decompile/compile loop).

[lukewagner]

At first I was confused by your use of "symbol" (interpreting "symbol" in the context of the hunk added to DynamicLinking.md by this PR) since immutable global pointers are post-MVP. But I think you're talking about "debugging symbols", as in the separate, optional module section which is purely added to assist projection of binary to text. In that case, I totally agree; I just added a section to TextFormat.md describing this interaction.

[jfbastien]

We (@ncbray, @flagxor, @lukewagner, @kripken, @sunfishcode) had a chat about this offline, and agree that this patch can indeed land as-is. We had concerns that for MVP we may want a more restricted form of globals to address specific performance concerns, and Mozilla folks expressed their willingness to revisit new-MVP-globals if/when data shows that we need to revisit.