[Feature] add Tailscale outbound (tsnet-based)

[cyenxchen]

Verification Steps

• I have read the documentation and confirmed that this feature is not implemented
• I have searched the Issue Tracker — related: [Feature] tailscale 有计划支持吗？ #2168, [Feature] tailscale 有计划支持吗？ #2520 (prior requests)

Description

希望为 mihomo 增加 type: tailscale 出站：内嵌 tsnet，让 mihomo 直接作为一个 Tailscale 节点接入 tailnet，把流量发到 tailnet 内的机器、或经由 exit-node 出网，无需在宿主机上单独跑 tailscaled，并保留 MagicDNS / split-DNS 解析能力。社区已有需求（见 #2168、#2520）。

对应 PR：#2784（约 2500 行 diff，含 tailscale.com 及其传递依赖），支持的配置项：auth-key / hostname / control-url（可对接 headscale）/ ephemeral / accept-routes / exit-node / 自定义 tsnet state 目录。同时附带为配合 tsnet 内部解析所做的收敛：net.DefaultResolver 投毒后保留受控逃生通道 + 进程级 guard、以及 SOCKS/Shadowsocks/Mieru/sing 入站 UDP 回包的域名回写（避免回包退化成 fake-IP）。

proxies:
  - name: ts-node
    type: tailscale
    auth-key: tskey-auth-xxxxxxxxxxxx
    hostname: mihomo-node
    # control-url: https://headscale.example.com   # 自建 headscale
    # ephemeral: true
    # accept-routes: true
    # exit-node: 100.x.y.z          # 或 exit-node 的 hostname
    # state-dir: /var/lib/mihomo/tailscale

关于 Go 版本（需要维护者拍板）

tailscale.com（实现里 pin 的是 v1.96.5）的 go.mod 第一行就是 go 1.26.1，依赖方下界继承——一旦 require 它，mihomo 的 go 指令就必须 >= 1.26.1，连带 test.yml 的 1.20–1.25 测试矩阵、build.yml 里 amd64-v{1,2,3}-go120 这些产物都会受影响。可选方案：

1. 直接把 go.mod 抬到 1.26，并相应精简旧 Go 版本的测试矩阵 / go120 产物（最简单）；
2. 把 tailscale 出站拆成独立的 Go module（主模块 go 指令不变，工程量较大）；
3. pin 更老的 tailscale.com release（功能/修复受限，且不保证与现有依赖兼容）。

注：单纯加 build tag 并不能避免 go 指令被顶高——只要任何 .go 里 import "tailscale.com/tsnet"，go mod tidy 仍会把该依赖留在 go.mod。

想先听一下维护者对「是否愿意接收这个出站」以及「Go 版本走哪个方案」的意见，再决定 PR 怎么收尾。

[wwqgtxx]

我们不反对这个出站，但是我们同样在短时间内不会为此放弃go1.20兼容性

从维护性上说，如果将官方tailscale fork出来，单独维护一个go1.20分支，我们也是可以接受的（如果你看我们的orgs会发现我们本来就维护了大量的backport包），同时也不会受到其内置直接使用net.Resolver的制约，因为可以直接替换成一个resolver接口

至于你那个PR嘛，只要最后的PR不要修改和此出站无关的功能（包括但不限于你的入站 UDP 域名回写，vet修正，加固和一堆意义不明的test），然后你能在tun模式下正常跑通不发生回环，还是有很大概率会接受的

[cyenxchen]

感谢回复，方向我接受，按你的建议来：

1. Go 1.20 兼容性：我会 fork tailscale.com、维护一个 go1.20 可编译的分支，PR 里只 require 这个 fork。想确认两点：
   • 这个 fork 你们倾向放哪？放进 MetaCubeX org（比如 metacubex/tailscale），还是先放我自己这边、review 通过后再转移？
   • 分支 / 打 tag 的约定有没有偏好（沿用上游 tag 加后缀，还是单独的版本线）？
2. net.Resolver：fork 之后我会把 tsnet 内部对 net.Resolver / net.DefaultResolver 的硬调用抽成一个 resolver 接口注入——这样原 PR 里那套 main.go 逃生通道 + defaultguard 进程级守卫就全部不需要了，会一并删掉。
3. 多余代码移除，照你说的，最终 PR 只保留 tailscale 出站本身（adapter/outbound/tailscale*.go、adapter/parser.go 注册、constant/adapters.go、go.sum）。下列与此出站无关的改动都从 PR 里移除：入站 UDP 域名回写、component/updater 那部分、fmt.Errorf 的 vet 修正、以及其它被牵连改动的包的测试。
4. TUN 模式回环：我会在 TUN 模式下实测 tailscale 出站，确认不与 mihomo 的 TUN / 路由相互回环，把测试方法和结果写进 PR。

[wwqgtxx]

ts fork先放你自己那，暂时不需要打tag，如果最后我们打算合并的话，会再进行迁移

此外对于ts内部的依赖也是一样的，尽量复用我们已有的metacubex下的fork（比如wireguard-go和gvisor这些）

[wwqgtxx]

#2786