@safe leak fix?

[Walter Bright]

Consider the code:

   @safe:
     T[] foo(T[] a) { return a; }

     T[] bar()
     {
         T[10] x;
         return foo(x);
     }

Now we've got an escaping reference to bar's stack. This is not memory 
safe. But giving up slices is a heavy burden.

So it occurred to me that the same solution for closures can be used 
here. If the address is taken of a stack variable in a safe function, 
that variable is instead allocated on the heap. If a more advanced 
compiler could prove that the address does not escape, it could be put 
back on the stack.

The code will be a little slower, but it will be memory safe. This 
change wouldn't be done in trusted or unsafe functions.