feat: add compat.sqlitecpp, compat.usockets and compat.uwebsockets

[Sunrisepeak]

feat: add compat.sqlitecpp, compat.usockets and compat.uwebsockets

第二批来自 SpinningMomo（Sunrisepeak/SpinningMomo#2）的 vcpkg → mcpp 迁移。这三个
有依赖边，正好把「包之间怎么接」这件事说清楚。

compat.sqlitecpp 3.3.3 → compat.sqlite3

上游用 git submodule 引 sqlite3。源码 tarball 不带 submodule，所以
sqlite3/sqlite3.c 根本不在归档里，库无法链接。依赖边替代了那个 submodule ——
而且是更好的安排：同一次链接里的两个 SQLite 消费者从此共享一份 amalgamation，
而不是各自内嵌一份带各自编译选项的副本。

两个 CMake 开关有意不设：SQLITECPP_USE_ASSERT_ON_ERRORS 把错误模型从抛异常改成
中止进程；SQLITE_ENABLE_COLUMN_METADATA 必须与 SQLite 自身的构建一致。两者都
该由消费者决定，头文件本来就用 #ifdef 守着。

测试特意都去够 sqlite3 的符号（版本串、预编译语句 + 绑定参数、回滚的事务、带
sqlite3 错误码的异常），因为这个包的核心问题是链接问题。

compat.usockets 0.8.8 → compat.libuv

三平台统一选 libuv 一个后端。uSockets 0.8.8 有四个（epoll/kqueue 仅 POSIX、
GCD 仅 macOS、libuv、asio），只有 libuv 能用一份源列表覆盖三平台；按平台各选
只会让 us_loop_t 每个平台一个形状而毫无收益。

SSL 关闭：crypto/openssl.c 与 crypto/sni_tree.cpp 不编，也不依赖
compat.openssl，于是基础包除 libuv 外零外部依赖。TLS 该做成 feature —— 在进程内
终结 TLS 是一个选择，没做这个选择的人不该为 OpenSSL 买单。quic.c(需 lsquic)与
eventing/io_uring.c(仅 Linux，且与「一个后端」的规则冲突)同样不收。

compat.uwebsockets 20.79.0 → compat.usockets

header-only，所以包本身只是 include root + 锚 TU + 那条依赖边。

三个包共同的那一条：INTERFACE 级的 define

LIBUS_USE_LIBUV / LIBUS_NO_SSL / UWS_NO_ZLIB 不是包的私事：

• libusockets.h —— 公开头 —— 会因 LIBUS_USE_LIBUV 改变 us_loop_t 的布局，
  并因 LIBUS_NO_SSL 门控 SSL 声明；
• uWS 是 header-only，它的模板是在消费者的 TU 里实例化的。

而索引描述符的 cflags 只作用于包自身的 TU。所以消费者必须自己声明这三个 ——
两个测试成员的 mcpp.toml 就是这么写的，注释也写明了原因。不一致不会构建失败，
而是内存损坏，所以 usockets 的测试从定时器回调里写 loop 附属的扩展内存再读回来：
布局一旦不一致，正是这条断言会断。

uwebsockets 的测试注册两种路由形状加一个 websocket behavior（各自实例化模板栈的
不同角落），再 listen(0, …) 让 OS 给临时端口并断言真的绑上了 —— 不会和 runner 上
任何东西撞端口。

验证

mcpp test -p sqlitecpp / -p usockets / -p uwebsockets   # linux gcc@16.1.0，各 1 passed

lint 全过。CN 镜像已建：gitcode mcpp-res/{sqlitecpp,usockets,uwebsockets}，
三个都验证过与 GLOBAL 字节一致。