支持服务管理

[hvvvvvvv]

适配以下平台的服务管理
SCM (Windows)
Launchd (MacOS)
systemd (Linux)
OpenRC (Linux)
rc.d (FreeBSD)

easytier-cli 添加子命令 service

子命令service支持的操作：
install
uninstall
status
start
stop

其中service-manager这个crate最新的release缺少一些功能，故暂时从github拉取，等到下一个release时，再修改为从crate.io拉取

[HKMV]

不错不错

[KKRainbow]

有个疑问，为啥不把启动/停止服务等操作放到 easytier-cli 里呢，然后在 cli 里把 core 注册成服务呢

[hvvvvvvv]

有个疑问，为啥不把启动/停止服务等操作放到 easytier-cli 里呢，然后在 cli 里把 core 注册成服务呢

最初我也考虑过这个问题，为此还在群里向你询问意见，但是没有收到回复。最终决定在core程序里实现主要是因为，如果在cli里实现，注册服务的时候想要验证core程序的启动参数不太方便，还有就是需要指定core程序文件的所在位置，个人觉得相对繁琐了点

[HKMV]

有个疑问，为啥不把启动/停止服务等操作放到 easytier-cli 里呢，然后在 cli 里把 core 注册成服务呢

最初我也考虑过这个问题，为此还在群里向你询问意见，但是没有收到回复。最终决定在core程序里实现主要是因为，如果在cli里实现，注册服务的时候想要验证core程序的启动参数不太方便，还有就是需要指定core程序文件的所在位置，个人觉得相对繁琐了点

个人认为不需要指定core程序位置，一般情况都会把core和cli放在环境变量中，以便于使用，可直接通过工具获取所在位置

[KKRainbow]

有个疑问，为啥不把启动/停止服务等操作放到 easytier-cli 里呢，然后在 cli 里把 core 注册成服务呢

最初我也考虑过这个问题，为此还在群里向你询问意见，但是没有收到回复。最终决定在core程序里实现主要是因为，如果在cli里实现，注册服务的时候想要验证core程序的启动参数不太方便，还有就是需要指定core程序文件的所在位置，个人觉得相对繁琐了点

抱歉，群里消息比较多，我经常会漏看。。

cli 和 core 一般放在一起（同一个目录），如果同目录没有检测到就直接给个报错应该就好了

放 core 里容易导致 core 体积增大，而且让 core 有一些非组网的功能，会让程序结构看起来比较奇怪，生成的二进制体积也会变大

[hvvvvvvv]

有个疑问，为啥不把启动/停止服务等操作放到 easytier-cli 里呢，然后在 cli 里把 core 注册成服务呢

最初我也考虑过这个问题，为此还在群里向你询问意见，但是没有收到回复。最终决定在core程序里实现主要是因为，如果在cli里实现，注册服务的时候想要验证core程序的启动参数不太方便，还有就是需要指定core程序文件的所在位置，个人觉得相对繁琐了点

个人认为不需要指定core程序位置，一般情况都会把core和cli放在环境变量中，以便于使用，可直接通过工具获取所在位置

我主要是偏向便捷性和各种环境的适应性，但是既然作者意见是放在cli里，那就再想想办法吧，哈哈

[hvvvvvvv]

有个疑问，为啥不把启动/停止服务等操作放到 easytier-cli 里呢，然后在 cli 里把 core 注册成服务呢

最初我也考虑过这个问题，为此还在群里向你询问意见，但是没有收到回复。最终决定在core程序里实现主要是因为，如果在cli里实现，注册服务的时候想要验证core程序的启动参数不太方便，还有就是需要指定core程序文件的所在位置，个人觉得相对繁琐了点

抱歉，群里消息比较多，我经常会漏看。。

cli 和 core 一般放在一起（同一个目录），如果同目录没有检测到就直接给个报错应该就好了

放 core 里容易导致 core 体积增大，而且让 core 有一些非组网的功能，会让程序结构看起来比较奇怪，生成的二进制体积也会变大

那我重新调整下

[KKRainbow]

我有个域名过期了，导致这些 case 受影响，晚点我修一下

[KKRainbow]

辛苦 rebase 下，重新跑下测试

[KKRainbow]

好像没有指定服务名的选项，如果是固定值的话是否意味着只能起一个服务？

[hvvvvvvv]

好像没有指定服务名的选项，如果是固定值的话是否意味着只能起一个服务？

那我再添加