tests/unix-tty: build on Darwin

[agorangetek]

What this does

Makes tests/unix-tty build on macOS. That suite is where a library built with
-dylib is loaded back through fb_DylibLoad() and resolved with
fb_DylibSymbol(), and it could not be built on Darwin at all — so nothing in
the tree exercised the dynamic-library path on Apple silicon.

Three things stopped it:

• tester.cxx uses std::optional, which needs C++17. Apple clang does not
  default to it, and compilation stopped there. The flag is now requested
  explicitly, which is a no-op for toolchains that already default to it.
• check_tty_state_is_equal() and dump_tty_state() compare
  termios.c_line, which is a Linux extension — the BSDs, Darwin included,
  have no such field. It is now guarded.
• The makefile hard-coded libexamplelib.so. Mach-O shared libraries are
  .dylib, so the extension is now taken from the platform.

Nothing is platform-specific in the other direction: on Linux LIBEXT resolves
to .so and the c_line check is still compiled in, so behaviour there is
unchanged.

Relationship to #479

The .dylib expectation matches the output naming fixed in #479
(darwin: name shared libraries .dylib, and export their symbols), which is
where -dylib on Darwin was repaired. On Linux this part is a no-op, so the two
can land in either order without breaking Linux; on Darwin they belong together.

Verification

make tests builds on Darwin with these, and the two dylibload testees pass on
Apple silicon:

testee-dylibload-only-examplelib          123 hello hello hello
testee-dylibload-dylibfree-examplelib     123 hello hello hello

Hiding the built libexamplelib.dylib makes the first one fail with
dylibload() failed, which is how I confirmed the loader is using the new name
rather than falling back.

The C++ tester itself still requires a real TTY to run — unchanged, and why I
ran the testees directly.