At the moment the API and implementation has implicit notion or restriction on native byte order endianness. This needs to be explicit with little/big endian support.

(Note vector lane endianness of lane order should not be an issue. It's specified to be little endian, i.e. the same order of elements in an array.)

The areas where endianness impacts are:

- vector access to byte[]. Currently implicit native endian access is performed. The load/store methods will need to be modified to accept a additional parameter declaring endianness.

- vector access to ByteBuffer. Currently the methods will throw an exception for a buffer whose order is not native.

- rebracket (and size constrained reshape). Currently rebracket does not change the bits of the vector in anyway, which should still be the case if native endianness is declared, but we will need an explicit parameter.