Memory management design

[BLM768]

Given all of this talk about memory management, it would seem 
that it's time for people to start putting forward some ideas for 
improved memory management designs. I've got an idea or two of my 
own, but I'd like to discuss my ideas before I draft a DIP so I 
can try to get everything fleshed out and polished.

Anyway the core idea behind my design is that object lifetimes 
tend to be managed in one of three ways:

1. Tied to a stack frame
2. Tied to an "owner" object
3. Not tied to any one object (managed by the GC)

To distinguish between these types of objects, one could use a 
set of three storage classes:

1. "scope": refers to stack-allocated memory (which seems to be 
the original design behind "scope"). "scope" references may not 
be stashed anywhere where they might become invalid. Since this 
is the "safest" type of reference, any object may be passed by 
"scope ref".

2. "owned": refers to an object that is heap-allocated but 
manually managed by another object or by a stack frame. "owned" 
references may only be stashed in other "owned" references. Any 
non-scope object may be passed by "owned ref". This storage class 
might not be usable in @safe code without further restrictions.

3. GC-managed: the default storage class. Fairly 
self-explanatory. GC-managed references may not refer to "scope" 
or "owned" objects.

Besides helping with the memory management issue, this design 
could also help tame the hairy mess of "auto ref"; "scope ref" 
can safely take any stack-allocated object, including 
temporaries, so a function could have "scope auto ref" parameters 
without needing to be a template function and with greater safety 
than "auto ref" currently provides.