Overhaul the termios API.

[sunfishcode]

Instead of defining Termios as an alias for the libc type, define our own type with a libc-compatible layout, so that we can use bitflags flags types, and have better overall ergonomics.

[sunfishcode]

I've now rebased and updated this.

And I've also added a major change: This now encapsulates the termios vs. termios2 difference on Linux, and supports arbitrary I/O speeds on both Linux and BSDs with a consistent interface.

This is a little higher-level than rustix typically aims for, but it doesn't incur extra syscalls or even extra Termios struct copies, and the things it hides are both awkward and uninteresting, such as the whole termios vs. termios2 split which only happens on Linux, where you have to use termios2 to support arbitrary speeds but you can't use termios2 with cfmakeraw etc., and also c_ispeed/c_ospeed work differently in termios2. And PowerPC lacks termios2 but has a termios that acts like termios2. And MIPS adds TCSETS to its TCSANOW etc. values.

[sunfishcode]

@SUPERCILEX This PR unifies tcgetattr and tcgetattr2 into a single framework that supports arbitrary speeds. I'd be interested to hear if this would work for your use case that motivated adding tcgetattr2 in the first place.

[SUPERCILEX]

My use case is literally just this lol: https://github.com/SUPERCILEX/hardcaml_riscv/blob/595a0992b3afac011a540daf9db0c1c4c3cc3b4c/soft/offchip/tstp/src/main.rs#L39

So I think this PR is good—can't test it though as I don't have my FPGA with me.

One thought: maybe it makes sense to have a set_speed method that only does the bit manipulation once?

[sunfishcode]

Sounds good. I've now implemented your idea of a set_speed function that sets both input and output, so your use case could look like this:

        let mut termios = tcgetattr(&device).unwrap();
        termios.set_speed(baud_rate);
        tcsetattr(&device, OptionalActions::Drain, &termios).unwrap();

This API takes care of the CBAUD and BOTHER parts for you.

So again, this is more than rustix would typically abstract away, and I'm still debating it, but there are so many portability hazards between OS's and architectures that I'm leaning towards it.

[SUPERCILEX]

This is awesome, thanks!

[sunfishcode]

This PR turns out to encounter what turned out to be some bugs in bitflags around the handling of unnamed bits. I've now added some workarounds to get the tests passing, but this will need some further planning.

[sunfishcode]

I've now filed #695 to track the workarounds.