Remove headers from ~@T and ~[@T] allocations

[alexcrichton]

I don't believe that these are needed in cleanup after all. Because ~T has the same semantics in the compiler regardless of what T is, then there are two cases for the destruction of ~T. One is before the program exits (which is normal), the other is when the program exits during annihilation. It's possible for ~T to be located inside an @ cycle.

Even though there were headers on ~[@t], the value itself was ignored because each of the elements were linked together themselves. Whatever box contains the ~ allocation will have its destructor run when annihilation comes around, subsequently freeing the ~ allocation.

This builds just fine on OSX, and I'm having other unrelated valgrind issues on linux to ensure that there's no leaks, but I'm sure bors will complain at me if there are any.

By the way, thanks to @thestinger's awesome work removing headers previously, this was a super-easy change!

[thestinger]

I think managed-unique does still need to be managed by the local heap, for the garbage collector to land. The headers can definitely be removed since they're unused, but it might be tricky to keep them using local_malloc and local_free without having the same representation as managed boxes.

cc @graydon

[alexcrichton]

@graydon agrees with @thestinger, the headers will be needed for the pending gc and its future iterations, so there's no real gains removing them now only to add them back later.

[thestinger]

@alexcrichton: I think it's more that local_malloc is needed rather than the headers themselves, but I'm not entirely clear on that.