Can we organize these functions better?

[Enet4]

We started nice and simple with a small number of functions. As pedantic and permissive variants emerged, we got 6. Then we sought to take vectors, adding 3 more to those. Soon, for each of default-many, permissive, pedantic, vec-default-many, vec-permissive and vec-pedantic, we'll be building one with safe POD transmutes, and probably two more for floating points and bools. This makes quite a panoply of functions, and we don't want people to get lost in them. Shall we categorize them better into namespaces (modules)? How many, and based on what criteria?

[Enet4]

With the Guard API, we now need much less functions than what we have now. For slices and vectors, we'd only need these:

fn guarded_transmute_slice<G: Guard, T>(bytes: &[u8]) -> Result<&[T], Error>;
fn guarded_transmute_vector<G: Guard, T>(bytes: Vec<u8>) -> Result<Vec<T>, Error>;

fn guarded_transmute_pod_slice<G: Guard, T>(bytes: &[u8]) -> Result<&[T], Error>;
fn guarded_transmute_pod_vector<G: Guard, T>(bytes: Vec<u8>) -> Result<Vec<T>, Error>;

fn guarded_transmute_bool_slice<G: Guard, T>(bytes: &[u8]) -> Result<&[bool], Error>;
fn guarded_transmute_bool_vector<G: Guard, T>(bytes: Vec<u8>) -> Result<Vec<bool>, Error>;

We could implement the ones above and deprecate some others. @nabijaczleweli What do you think?

[frankier]

I feel like perhaps pod and bool could stay in their own namespaces rather than being re-exported in the root? Might that help the crate feel more organised?