Improve generic usage of Pixel trait

[rom1v]

In order to use either u8 or u16 for plane components, a Pixel trait regroups several "capabilities" that a generic pixel type must support, through trait inheritance.

That way, a generic function can just use the Pixel type, without listing them all:

fn f<T: Pixel>(...) { ... }

However, trait inheritance cannot express constraints about T for other types (like i32: AsPrimitive<T>). As a consequence, callers had to specify these additional constraints manually:

where
    T: Pixel,
    i32: AsPrimitive<T>,
    u32: AsPrimitive<T>,

This is redundant, because if T is a Pixel, then i32 and u32 necessarily implement AsPrimitive<T> (since Pixel is only implemented for u8 and u16).

To express these relationships, create a new trait, CastFromPrimitive<T>, representing the inverse of AsPrimitive<T>.

This paves the way to make Plane (and many other structures) generic over the pixel type conveniently.

---

Since Pixel is only implemented for u8 and u16 types, it is always possible to cast a Pixel to an integral primitive type. However, the compiler could not know this, because in theory any other type could also implement the Pixel trait.

To enforce this restriction, make the (main) integral primitive types implement CastForPrimitive<T> for any T which implements Pixel. That way, the compiler knows that a Pixel (whatever its concrete type) can always be cast to an integer.

Then, rewrite the constraints on convert_slice_2d() to use CastFromPrimitive, so that callers need not to add redundant constraints if T implements Pixel.

[tdaede]

Ah neat, when I originally wrote this I wasn't aware of CastFromPrimitive. This makes more sense.

[rom1v]

@tdaede

I wasn't aware of CastFromPrimitive

I just defined it in this PR.

(it could be better to implement it upstream, in the num crate).

[tdaede]

Aha, didn't finish scrolling :)

[tdaede]

Looks like the changes need to be made to some of the tests as well.

[coveralls]

Coverage decreased (-0.005%) to 79.269% when pulling caabe30 on rom1v:castfrom into 82a5270 on xiph:master.

[lu-zero]

Might be noted that it is similar to the yet-to-stabilize try_from()

[rom1v]

@lu-zero

Might be noted that it is similar to the yet-to-stabilize try_from()
Yes, but try_from() returns a Result<usize, TryFromIntError>.

Here, in non-generic code, we just use v as u16 or v as u8, without additional checks, so I guess we want the same behavior in generic code.

[tdaede]

Thanks, quickly merging before we break it again :)