add MoveItems to RingBuf, fixes  #19085

r? @huonw @csherratt
I'm not certain about this change. `offset` lowers into an LLVM `GetElementPtr` with an `inbounds` annotation. According to [this LLVM documentation](http://llvm.org/docs/GetElementPtr.html#what-happens-if-an-array-index-is-out-of-bounds),

> With the inbounds keyword, the result value of the GEP is undefined if the address is outside the actual underlying allocated object and not the address one-past-the-end.

Since there is no underlying allocated object, this is a bit unclear, but it seems to imply that using an `inbounds` GEP on some random pointer produces undefined results.

This may be fine, as Rust never actually tries to dereference zero size pointers, and in [another part of the same page](http://llvm.org/docs/GetElementPtr.html#can-i-cast-an-object-s-address-to-integer-and-add-it-to-null) discussing computing an address from null (analagous to what you are doing here), the docs say that

> The underlying integer computation is sufficiently defined; null has a defined value — zero — and you can add whatever value you want to it.
>
> However, it’s invalid to access (load from or store to) an LLVM-aware object with such a pointer. This includes GlobalVariables, Allocas, and objects pointed to by noalias pointers.

Unfortunately, that section is talking about plain GEP, without the `inbounds` marker. Even if LLVM currently doesn't do anything weird that would cause this to break, I think using offset here is technically invalid.

(Also, if this does turn out to be valid, this pattern of avoiding `offset`s of 0-size pointers is common, and all cases would be presumably simplified by using `offset`.)