Consider exposing `as` type-casting

[cuviper]

This is an interesting case because as is a language feature, not library, but I think we can probably still justify it in num-primitive's niche. We have a chance to redesign num_traits::AsPrimitive<T> here though. For example, I think I'd rather not have bounds on the parameter T -- they're not propagated so you have to repeat those if you're using generic T elsewhere, like where Self: AsPrimitive<T>, T: 'static + Copy.

Renaming as well to fit in this crate, I'm thinking something like:

trait PrimitiveNumber {
    // ...

    fn as_from<T>(value: T) -> Self
    where
        Self: PrimitiveNumberAs<T>;

    fn as_to<T>(self) -> T
    where
        Self: PrimitiveNumberAs<T>;
}

trait PrimitiveNumberAs<T>: PrimitiveNumber {
    // hidden and sealed methods
    fn __as_from(T) -> Self;
    fn __as_to(self) -> T;
}

This allows turbofish for cases that type inference might stumble on, e.g. angle.as_to::<f64>().to_radians().

(Similar to the current setup of PrimitiveFloatToInt)