Use stty as fallback provider (fix #225 and #251)

[Glavo]

This PR is based on #270 and #272, I will clean up the changeset via rebase.

Reply to Guillaume's question

While I'm very glad you work on all those new features, but I'm really starting to wonder if it would make more sense to somehow merge jansi inside jline at some point, keeping jansi the low level library for jline capabilities. It really looks like a lot of duplication to me with all those providers, are a lot of this code is already present in jline and we're just missing the FFM (PR ready) and the new static-native one.

1. MingwSupport contains most of the things we need, so this PR will not introduce more duplicate content with jline3 here. In fact, this PR is only ten lines of code.
2. This PR is not useless, it really solves some problems that bother users:

• I am a user of linux-loongarch64. loongarch64 is a new architecture and it already has many users, but since it's so new it's hard to find a docker image that includes the necessary cross-compilation toolchain, so I can't submit jni support for it at the moment;
• On Linux the jni library is linked to glibc, but users may use other libc. Add support for Android #225 and Failed to load native library:jansi-2.4.0-1ba1a04f0d4ec9d-libjansi.so. osinfo: Linux/arm #251 are crashes caused by trying to link the jni library to bionic libc. Besides Android, there are still many users using musl libc. While musl libc seems to offer some compatibility with glibc, they don't give solid guarantee. I think it makes sense to provide more stable support.
• FFM support is currently unable to resolve the above issue. It is foreseeable that Java 8/11/17 will still have a large number of users for a long time, and even in Java 21 FFM is still a preview feature. We cannot rely too much on FFM support just yet.