Add OppositeNativeEndian alias

[Enet4]

This PR is merely a proposal for an addition that is indeed awkard: an alias for LittleEndian in a big endian system and BigEndian in a little endian system. However, I stumbled upon a use case where it is actually useful, and I thought of at least sharing it.

The NIfTI-1 data format does not specify a byte order for the file, so its contents could be in either endianness. In order to detect the file's byte order, the specification of the format itself advises implementations to check the value of a very specific field (dim[0]), and swap all fields if it's not between 1 and 7. An efficient solution would begin reading the header in system-native endian up to this value, and choose whether to continue reading the same way after dim[0] or swap everything before that and continue with the opposite byte order. It becomes an elegant solution when separated in two functions.

Of course, given the nature of this alias and its trivial implementation, feel free to close this PR if you think it doesn't quite fit in.

[BurntSushi]

Hmm. So I was actually hesitant to bring in the NetworkEndian alias (see #44), which has far broader appeal than this. I grant that while you might have a valid use case, I propose that:

1. You can create these type aliases yourself at very little cost.
2. I wager you might be one of the few people to ever do so.

I've been very stingy with the byteorder API. I personally think we need more compelling data points than what's given here.

[Enet4]

I am fine with that, and I understand your concern of keeping the API clean. I guess I'll take the initiative of closing this. Kind regards.