Add PacketOwned variants

[maximeborges]

This PR allows to copy parsed packets into data-owned packets that can be moved to other threads.

I'm not really happy about duplicating all the packets and having big matching tables here, but I'm not really sure how else this could be implemented. Maybe refactoring so you have PacketOwned as a base data structure that you can borrow from to get PacketRef.

Also unintentionally run cargo fmt so it cleaned up some other code, which is not that bad in the end (but I can split that into two commits at least if it helps for the review).

[gwbres]

@maximeborges very good contribution 👍

[lkolbly]

Is it possible to put this behind the alloc flag? (for clients who haven't defined an allocator)

[lkolbly]

I think this is the only place affected by my alloc comment above, correct me if I'm wrong.

[lkolbly]

Thanks for the PR! I concur, it's a little weird that we have to duplicate the struct (and methods). I think we do have to do that, though: If the owned variant was a base that the ref referred to, then I don't think we could do the zero-copy thing that Ref can do (where it references some buffer that the user holds)

...that said, maybe we could do something clever with traits and default methods. You could imagine a trait like so:

pub trait SomePacket {
    fn latitude(&self) -> u32 {
        u32::from_le_bytes(self.bytes()[0..=3].try_into().unwrap())
    }
    
    fn bytes(&self) -> &[u8];
}

and then you could have PacketRef and PacketOwned each implement the bytes method, like so:

pub struct PacketRef<'a>(&'a [u8]);
pub struct PacketOwned([u8; 4]);

impl<'a> SomePacket for PacketRef<'a> {
    fn bytes(&self) -> &[u8] {
        self.0
    }
}

impl SomePacket for PacketOwned {
    fn bytes<'a>(&'a self) -> &'a [u8] {
        &self.0
    }
}

Which also lets you write code that's agnostic to ref or owned:

fn extract_field(bytes: impl SomePacket) -> u32 {
    bytes.latitude()
}

pub fn cvt_bytes(bytes: [u8; 4]) -> u32 {
    let p = PacketOwned(bytes);
    extract_field(p)
}

Which, as always, compiles entertainingly well.

Anyway, I'm sure we could go on forever down that rabbit hole. Maybe we can roll it into #43 somehow. For now though, this looks good, barring my comment about alloc.