Provide `char`-based API

[mkroening]

A char-base API can be used for easy conversion of chars, so one does not need to access the maps manually and perform the shift by 128 and so on and so forth.

I am thinking of an API like this:

#[derive(Clone, Copy, Debug)]
#[repr(transparent)]
pub struct Cp437(pub u8);

impl Cp437 {
    pub fn from_char_lossy(c: char) -> Self;
}

impl TryFrom<char> for Cp437;
impl From<Cp437> for char;
impl fmt::Display for Cp437;

This could be the base for the provided string-based API as well.

Would you be open to a PR?

[tats-u]

I wonder if other crates treat custom structures defined by this crate (e.g. Cp437) as the common u8. Also used code pages may be vary in response to options of programs or locales of users, so I think we have to provide APIs like <code page (table) structure>.{en,de}code_char_* or {de,en}code_char_checked.

[mkroening]

I wonder if other crates treat custom structures defined by this crate (e.g. Cp437) as the common u8.

The inner u8 would still be accessible, and the representation is transparent, so it can be used in places where u8 was used before.

Also used code pages may be vary in response to options of programs or locales of users, so I think we have to provide APIs like <code page (table) structure>.{en,de}code_char_* or {de,en}code_char_checked.

Yes, that sounds good.

I'll work on this after https://github.com/tats-u/rust-oem-cp/pull/9, but it might take a while. I am quite busy at the moment.

[tats-u]

@mkroening Can and should we make CpXXX structures implement a common trait? If so can we switch CpXXX structures in response to other variables (arguments and locales for example)? Anyway I think {en,de}code_char_* have higher priorities.

[tats-u]

@mkroening Fixed in https://github.com/tats-u/rust-oem-cp/commit/c690b988bd69f9747d37fe4fc1c24fd4f051d3f3. I'd like you to try the master branch if possible. I'm planning to release v3.0.0 in the near future.