Issue Description:

For collections that are range replaceable and random access, in principle it ought to be possible to implement relatively fast move operations. In some cases, such as arrays over primitive types, this operation can literally delegate to memmove.

Unfortunately, there is no way in safe Swift to express this requirement. Here is a Compiler Explorer page that shows a reasonable implementation of memmove on [UInt8]. I've reproduced it below:

extension Array where Element == UInt8 {
    mutating func moveRange(offset: Int, range: Range<Index>) {        
        // A fully general implementation will have a way to zero-extend
        // the array, but no performant solution exists for that either.
        // Therefore we precondition that the move is entirely in-bounds.
        precondition(range.lowerBound >= self.startIndex)
        precondition(range.upperBound <= self.endIndex)
        precondition(self.index(range.upperBound, offsetBy: offset, limitedBy: self.endIndex) != nil)
        precondition(self.index(range.lowerBound, offsetBy: offset, limitedBy: self.startIndex) != nil)

        if offset > 0 {
            for index in range.reversed() {
                self[self.index(index, offsetBy: offset)] = self[index]
            }
        } else {
            for index in range {
                self[self.index(index, offsetBy: offset)] = self[index]
            }
        }
    }
}

Currently, the compiler cannot observe that the preconditions written in this function are sufficient to cover all possible subscripting errors, and nor can it hoist the bounds checks. The end result of this is that the memmove is done byte by byte, checking that every index is in bounds (as we know it will be).

Note that replaceSubrange cannot be useful for this. Because of replaceSubrange's generality, passing a slice of self into that call will cause a CoW operation. Again, even if the optimiser can solve this for inlinable code, it cannot solve this across resilient module boundaries, where the compiler must be pessimistic.

I can see only two routes out of this. The first is to make the optimiser smarter. This seems extremely hard, particularly for types that have complex index objects, such as NIO's CircularBuffer, and it's outright impossible for resilient types.

An alternative option is to have a protocol that can express that a type is capable of a performant object move. This is like RangeReplaceableCollection: indeed, it'd be something line RangeMoveableCollection. This could be implemented as a move(range: Range<Index>, to: Range<Index>), could perform only the 4 bounds checks required, and then perform a direct copy without needing further bounds checks. These copies can vectorise on trivial types.