Add Mark and Space variants to Parity enum

[YgorSouza]

Closes #167

[YgorSouza]

Note that since the Parity enum is not marked #[non_exhaustive], this is a breaking change and requires a major version bump.

Also, I have not tested this yet, and I'm not sure I'll have access to a serial device with mark/space parity to test soon. If someone else could test, that would be appreciated.

[sirhcel]

I would provide Parity::Mark and Parity::Space only for backends actually supporting it.

[YgorSouza]

I finally managed to test this a bit, at least the Space variant, on Windows 11 and on Linux (Fedora 43 GNOME on a Thinkpad E480)

TLDR: everything works fine on Windows. On Linux it works partially, but I'm not sure if the problems come from the code or from my USB adapters.

Details

The instrument I used is the APX-200 analytical balance, from Denver Instruments. As I don't have a physical RS-232 port, I tested with two different USB to Serial adapters.

I only tested the two commands I use:

• Print (\x1bP\r\n) makes the balance return a measurement in a form similar to - 13.7293 g \r\n
• Tare (\x1bT\r\n) tares the balance

I didn't want to mess with the balance's configurations, in case it would stop working with the program I already have. I have an old piece of C# code that configures the port with 7 bits of data and space parity. It works on Windows with one of my adapters, but not the other, and doesn't work at all on Linux, and I haven't had time to debug it. I figured it could work the same with 8 bits of data and no parity, so I tested that as well in Rust. The C# code also sets RtsEnable and DtrEnable to true, so I set .flow_control(FlowControl::Hardware), which seemed to be the equivalent in this library. The communication worked with this and didn't work without it. Baud rate is 9600 and the other settings are default.

On Windows, everything worked perfectly. Both with 8 bits + no parity, and with 7 bits + space parity, with both USB adapters. Except that one of the adapters cannot be reopened once closed (it returns "A device attached to the system is not functioning"), until it is physically unplugged and reconnected. This also happens with version 4.8.1 from crates.io, and I don't think it is a problem with the crate. It's just my adapter being weird.

On Linux, everything worked with 8 bits + no parity, with both adapters. With 7 bits + space parity, I had these results:

• Adapter 1: Print command works, but the response sometimes has some or all characters replaced with \0. Tare command does not work
• Adapter 2: Print command works, and the response is correct. Tare command does not work

So it is strange that the Print command works but Tare does not, when they are almost the same, and also that the response is different depending on the adapter. There might be some incompatibility between the adapters and Linux, which leads to these bugs. It would be good to test with some other library, like pyserial, to see if I get the same results, to confirm that the problem is with my adapters and not the crate. I'll see if I can get on that.