TempAlloc: Request for Review For Inclusion in core.memory

[dsimcha]

== Quote from Dmitry Olshansky (dmitry.olsh at gmail.com)'s article
> slackCat should probably use the common type, not the first one passed?

Good point.  Will fix.

> Also it would be cool to have addRange/removeRange somehow automated for
> types that have indirections.
> Or it's too much state to carry around?

Yeah, I don't want this because a major purpose of TempAlloc is to allow efficient
parallelism, and addRange/removeRange involves locks.  Besides, I think they use
linear search in the current GC implementation rather than something more
efficient.  Once you're doing stuff like this, the advantages of TempAlloc go away
rapidly.  Besides, it's perfectly safe (at least now, while the GC isn't moving)
to store a reference to GC memory in TempAlloc, as long as it's not the **only**
reference.  It's also perfectly safe to have indirections from TempAlloc data into
other TempAlloc data, as long as the LIFO freeing order isn't violated.