feat: add compat.nanodbc and compat.unixodbc - #210

nanodbc is a thin C++ wrapper over the platform ODBC driver manager,
frozen upstream at v2.14.0 (March 2022). Two fixes make the four-year-old
source compile and run under the mcpp toolchain:

- a force-included char_traits<unsigned char> shim for libc++ (the
  standard's own customization point, guarded on _LIBCPP_VERSION;
  delivered via cxxflags, since cflags never reaches .cpp TUs)
- a per-platform answer to the driver manager: windows links the SDK's
  odbc32, macOS the OS's iODBC, and linux takes the new compat.unixodbc,
  because mcpp's runtime closure rejects a NEEDED libodbc.so.2 that only
  the host can provide (its PT_INTERP is a private loader)

compat.unixodbc builds the unixODBC 2.3.14 driver manager statically
from source (Shape E over A): DM + odbcinst + ini/log/lst + libltdl in
one odbc target, exactly upstream's libodbc.a symbol set, so consumers
carry no libodbc.so.2 NEEDED at all. The non-obvious pieces, both
verified against the libtool build of the same tarball:

- libtool-free ltdl wiring: -DLTDLOPEN=libltdlc plus a generated
  lt_libltdlc_LTX_preloaded_symbols table (reconstructed from the
  libtool object's relocations) registers the dlopen loader
- one merged config.h: ltdl's configure output folded into the
  top-level one (ltdl sources never read the clashing macros),
  sidestepping a quoted -DLT_CONFIG_H that does not survive the
  descriptor -> command-line pipeline

The member test is deliberately database-free: connecting to a
nonexistent DSN must throw nanodbc::database_error, and the SQL state
prefix plus the manager's own message text prove the diagnostics came
from the real driver manager. nanodbc 2.14.0's frozen off-by-one (it
drops the last SQL-state character) is asserted as a prefix, not
equality.

Verified: mcpp test -p nanodbc 1/1 cold with no host paths; all lint
scripts; mcpp xpkg parse for all 98 descriptors under the pinned
2026.8.10.3; sha256 double-checked for both tarballs. CN mirrors are
plain-string GLOBAL for now (no mcpp-res write access), same fallback
as compat.libmysqlclient.

… error

With string_view support on (C++17+), NANODBC_INSTANTIATE_BIND_STRINGS
over std::string and std::string_view emit identical explicit
instantiation definitions (both reduce to value_type = char; likewise
the u16 pair). Same TU, identical specializations, semantics unaffected
-- but GCC (the linux default leg) rejects duplicates where clang
accepts silently. CI run 31890353516, workspace (linux default).

-fpermissive is GCC's own downgrade for exactly this diagnostic and
clang ignores the flag, so the linux leg serves both toolchains.