Document ABI guarantees

[m-mueller678]

The current implementation of ArrayVec uses repr(C), which allows passing it between separately compiled rust programs. This is nice. It would be great to have documentation on which parts of the ArrayVec ABI are considered stable and which are considered to be implementation details. Specifically, I care about these questions:

• Will future versions of ArrayVec<T> have the same data layout as the same future version of ArrayVec<T> compiled separately?
• Will future versions of ArrayVec<T> have the same data layout as the current version of ArrayVec<T>?
• Do ArrayVec<T> and ArrayVec<U> have compatible layouts if T and U are compatible? e. g. can I transmute ArrayVec<u32> to ArrayVec<UnsafeCell<u32>>

[bluss]

It would be good to first untangle the thread of why the repr(C) attribute is there in the first place. It's there because of #255 only, not because of any other reason.

[m-mueller678]

I would suggest guaranteeing at least points 1 and 3, as I do not see any reason ArrayVec would ever want to become repr(Rust) in the future. Point 2 does limit future design and I would not recommend guaranteeing that. If you do not want to make any stability guarantees, I am also happy to just stick with the current version, which works for my use case.