Add testing for libtty.js

[hoodmane]

Add testing of the TTY interface defined in libtty.js.
Make ttyops.fsync optional, if not present fsync() is a no-op.

Before this PR, there was no coverage for TTY.register() other than the features used in default_tty_ops`.
This new tests creates and registers new TTY devices using TTY.register() and then excercises them via the native C file APIs.

The TTY API is undocumented and slightly ill-considered but people are using it so it's good to have some test coverage.

[sbc100]

I do wonder if this unterface (get_char, put_char, ioctl_tcgets, ioctl_tcsets, ioctl_tiocgwinsz) is actually the right one, but I suppose its what we have today so putting some testing in place is probably a good thing!

Also, as always with FS changes, it begs the question if whether we should be working on old FS changes to focusing on WasmFS going forward?

[hoodmane]

get_char and put_char is definitely terrible. I don't have as strong of an opinion on the others but it's certainly not clear they are a good interface. If we do change any of this behavior, we can update the test and that will clarify what behavior changes are happening.

we should be working on old FS changes to focusing on WasmFS going forward?

I'm still using the old FS extensively and the migration is going to take a long time. For instance, I'll need to repeat the project to get the CPython test suite happy with old FS on WasmFS.
python/cpython#127146
Then there is the issue of all my custom FS code that has to be ported, and lots of small differences of behaviors to be understood and papered over or documented, and the fact that different file systems are supported between WasmFS and old FS so we need to understand who is using the file systems that are not supported and what their migration path will be.

So in the meantime for me it is certainly worth improving the old FS. Not sure about for you.

[sbc100]

So this change also make the fsync operation optional for tty objects? Or was it always optional, but not tested?

[hoodmane]

It wasn't optional but in my opinion it should be.

[sbc100]

Can you mention this in the PR description?

[sbc100]

lgtm % comments

[hoodmane]

@sbc100 I think I addressed the comments.

[sbc100]

Maybe you should add some more context to the PR description.

Something like:

Add some testing of the TTY interface defined in libtty.js. This new tests creates and registeres new TTY devices using TTY.regsiter() and then excersizes them via the native C file APIs. Its not clear that this is really part of the public emscripten API, but since we are dealing with JS here all our internals are kind of exposed, and its certainly possible folks are using this API register their own TTY-like devices.

[hoodmane]

Its not clear that this is really part of the public emscripten API

Are we meant to infer that it's not because it's undocumented? It certainly isn't explicitly indicated anywhere that it is not public and it is exported even though with MODULARIZE or EXPORT_ES6 it would possible not to export it.

its certainly possible folks are using this API register their own TTY-like devices.

Also I believe people are mutating TTY.default_tty_ops.

[hoodmane]

Also, I'd imagine that whoever introduced ioctl_tcgets, ioctl_tcsets, and ioctl_tiocgwinsz is either overwriting them in TTY.default_tty_ops or is defining their own TTY with nontrivial definitions for these.

[hoodmane]

Okay updated the PR description.