Make UnixSteam generic on the queue size

[sbosnick]

The various UnixStream implementations currently use a fixed size for the internal queue of file descriptors. This is current fixed at 2, though there is no particularly good reasons for this value.

The constrains on the size of the internal queue are as follows:

1. it should be fairly small (at least by default) because it is used to calculate the size of an array allocated on the stack
2. it should be the same on both sides of the "fd passing" (assuming both processes use this library)

The reason for the second constraint is to try to avoid the control data being truncated in the underlying call to recvmsg. This crate treats this occurrence as an error though the call to recvmsg implements it as a flag set on the msghdr structure passed as a parameter.

The second constraint also makes it a breaking change to increment the current fixed value across the board because you could end up with the sending side using a larger fixed value than the receiving side which would risk errors due to the control data being truncated on the underlying call to recvmsg.

The proposed (and non-breaking) change to allow users of the crate to have a larger (though still fixed) queue size is to make the various UnixStream implementations rely on a const generic parameter for the queue size (which would default to the current 2 to keep the change non-breaking). The proposed interface is:

pub const DEFAULT_FD_QUEUE_SIZE: usize = 2;

pub struct UnixStream<const N: usize = DEFAULT_FD_QUEUE_SIZE> { ... }

impl<const N:usize> UnixStream<N> {
    pub const FD_QUEUE_SIZE: usize = N;

    ...
}

It may be desirable to increase DEFAULT_FD_QUEUE_SIZE for the next major release but for now we would keep it at 2 to avoid a breaking change.

[sbosnick]

The design presented above leads to an error on stable Rust with the use of the generic const parameter N in the calculation needed for the stack array size (which ultimately ends with a call to the now const fn libc::CMSG_SPACE). This error goes away with the incompletely implement #![feature(generic_const_exprs)] on nightly so it may eventually be possible to use a stack array for this purpose.

As an interim solution (until #![feature(generic_const_exprs)] is stabilized) I will try a solution using smallvec instead of a stack array.