Remove dependency on byteorder crate, make byteorder type methods const

[joshlf]

Summary

Remove our dependency on the byteorder crate and remove the byteorder feature, making the byteorder module available unconditinoally.

Progress

In progress in #583.

• Update #583 to have const fns no longer be const so that it works with our MSRV
• Support functions which are conditionally const depending on Rust version (as prototyped in #574)
• Make byteorder functions conditionally const

Description

Some potential users have expressed concerns over our dependency on the byteorder crate. I have not seen any uses of the types in our byteorder module which mix those types with other uses of the byteorder crate, which implies that we could just define our own ByteOrder trait rather than using the one from the byteorder crate and this wouldn't cause problems for users.

While we're at it, we could use a technique like the following to allow the methods on our types to be const fns:

use core::marker::PhantomData;

pub trait ByteOrder {
    #[doc(hidden)]
    const ORDER: Order;
}

#[doc(hidden)]
pub enum Order {
    BigEndian,
    LittleEndian,
}

#[repr(transparent)]
pub struct U64<O>([u8; core::mem::size_of::<u64>()], PhantomData<O>);

impl<O: ByteOrder> U64<O> {
    pub const fn new(u: u64) -> U64<O> {
        let bytes = match O::ORDER {
            Order::BigEndian => u.to_be_bytes(),
            Order::LittleEndian => u.to_le_bytes(),
        };
        
        U64(bytes, PhantomData)
    }
}

[digama0]

Do you intend to implement the ReadBytesExt and WriteBytesExt traits from byteorder? I was previously using zerocopy and byteorder together for this reason, but it's awkward that I now have to deal with conflicting LittleEndian types.

[joshlf]

What's your specific use case? Can you provide some example code? There's an existing discussion about supporting readers and writers: #158

[digama0]

I managed to work around the issue in my actual use case. You can see the code using both the byteorder LE and the zerocopy LE renamed to ZLE. You can search for other uses of LE and ZLE in the file. This is a binary parser, which is reading a binary format using zerocopy and writing another binary format in streaming fashion, usually one integral value at a time. Endianness is important in both cases, but I can't use the same LE type because zerocopy's LE doesn't implement byteorder's traits and vice versa.