Fix max CCS fingerprint

[Fangliding]

这样应该就没问题了 就是被探测的网站根据行为可以知道被设置为reality dest了 或者像之前说的允许用户手动设置 嗯。。。

话说我都没这仓库的write权限((

[Fangliding]

目前的局限性有几个
网站会知道你在用reality指向它（这种探测过于明显）
大多数网站需要64倍rtt的时间完成探测（不过应该没人dest选延迟太高的服务器给自己找补吧） 如果延迟比较低比如30ms那两秒不到可以探测完成
理论上在极端网络波动下下小于32的服务器可能返回一个略大的值 比如16变成17
部分网站的行为是无限 我拿3xui的内置表试了下 aws因为使用自有TLS实现 实际限制是无限（97是探测工具写的探测上限不是实际）

还有几个方案
1 固定四个挡位 1 16 32 ∞ 探测出它们比较简单
2 用户手填 不探测了 默认就 32 可以满足大多数情况

[kyber1024]

有无可能类似TLSmirror那样把不来自可信客户端的所有流量,包括但不限于不合法的client hello,未通过协商的密钥加密的包,全都发给dest.但是者意味着需要为每一个用户的连接维护一个匹配的和dest的tls1.3连接.好处可以解决几乎所有的edge case

[RPRX]

已知 Golang TLS 的 NewSessionTicket 都在 ClientFinished 前，或许可以简单些？

另外应当像 uTLS 库一样标出哪些修改专属于 REALITY，防止以后再被误改

[Fangliding]

不太行 各家TLS有的有一定程度魔改 比如cloudflare 虽然max ccs是32 但是它和golang一样不会在握手完成后立即发这个有特征的NewSessionTicket

[Fangliding]

而且这个PostHandshakeRecords不一定来自NewSessionTicket消息 它还可能来自h2服务器看到h2 alpn后发来的一些前置信息

[RPRX]

主要是我测试 REALITY 都是本地跑的那不就把我卖了，虽然这完成了探测的 TODO

record_detect.go 就别改名了吧，另外哪里是 REALITY 针对 TLS 改的部分标一下，防止再同步错了