Scoped allocation

@dpgeorge's comment is from here:

I'm thinking: @micropython.temp serves as a context which results in a C-call to switch a malloc function

Yes, I think this is a pretty decent idea. I had a similar idea for a while which is "scoped allocation", whereby all allocations within a function call are allocated in a new "heap scope", and then the entire scope is freed upon exit of the function. Eg:

@micropython.heap_on_stack(200)
def foo(x, y):
l = [x, y]
return len(l)
The idea here is that the function foo() is wrapped in a new heap and the semantics of calling foo are:

200 bytes are allocated on the C stack and used to create a temporary "heap"
allocation on this heap is simply a matter of incrementing a pointer and checking that it didn't go beyond the extents (of 200 bytes in this case); there is no GC'ing of this temporary heap
all malloc/free functions in the runtime are switched to use this temporary heap for the duration of the foo execution
the function foo runs, allocates a new list, computes its length, and returns this integer
as foo returns the temporary heap is destroyed, along with all objects created on it (in this case the list l)
the result of foo is a small int and doesn't need the heap and is returned to the caller
The execution of foo is highly deterministic, in terms of memory use and execution time. Using scoped allocation allows you to allocate in a hard interrupt. The downside of this approach is that foo must not leak any scope-allocated objects into the outer scope, because these objects won't exist once foo returns. Note also that you can nest the allocation scopes.

No files, tests, or entry points are named. Start by tracing MicroPython's runtime allocation paths and the decorator behavior described in the issue; define the scope semantics, nesting and object-lifetime constraints before implementation, with tests covering allocation and cleanup.