feat: add compat.sqlitecpp, compat.usockets and compat.uwebsockets - #215

第二批来自 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 字节一致。