should error on resize of foreign-buffer arrays

[Keno]

Right now we allow buffers which Julia did not allocate itself to be resized by allocating a new buffer and copying the data over.
Instead @JeffBezanson and I came to the conclusion that it would be a good idea to disallow any kind of operation that could change the memory in which the array is allocated (mostly resize). This would also allow us to expose an Array API as well as having a convenience MmmapArray API for mmaped Arrays, where the former would essentially only allow get/set.

[timholy]

I personally like the idea of a separate MmapArray type.

[JeffBezanson]

To clarify, the intent of this issue is just to give an error for resize! on an array where julia didn't allocate the memory.

[StefanKarpinski]

The amount of trouble caused by being able to resize arrays often makes me wonder if it's worth it.

[JeffBezanson]

Well, it causes trouble because it's so powerful.

There is a decent chance we should have a dequeue type of some sort instead, and the ability to make an Array from one without copying. IOBuffer could probably be modified to fill this role; then you would incrementally build arrays the same way as for strings.

[StefanKarpinski]

Yeah, that's kind of what I was thinking. It seems to me that it's uncommon to both need to build an array incrementally and need it to have contiguous layout. You generally build things incrementally when you just want to compile a list of things. One thought is that cell arrays could be a distinct type from Array{Any} and be growable.

[JeffBezanson]

Growable byte arrays are clearly necessary at least.