改进的错误支持，MessageSegment::type重构为enum，对MessageSegment的其他重构和优化

[dynilath]

No description provided.

[ExerciseBook]

@dynilath 用枚举型不好吧，你永远不知道xx能给你整出什么新活儿。

[stdrc]

发送和接收的 CQ 码是有不重叠的，有些只能收不能发，还有的 CQ 码只有 Pro 能收，还有就是 酷Q 随时可能有新的 CQ 码，可能还是保持字符串比较好

[ExerciseBook]

我觉得这个可，但是我觉可能需要个完整一点的表？

-23 （目标无效） 啥的都没有

[dynilath]

可以考虑用枚举表达常用的、能由用户构造的类型。其他的塞进一个other枚举里。在map里存{type,data}，或者用其他更直观的表示（其实要用的都已经在前面所说的情况里了，很可能是根本用不上）。
实际上现在这个对于无法辨认的CQ码就用unimpl表示类型。并且为那些返回MessageSegment类型的static方法提供了枚举型支持。

[ExerciseBook]

既枚举又保留扩展性的看起来不错。

[dynilath]

INVALID_TARGET的确是没找到哪里有用到。（总之先摆一个这里放着。）

[ExerciseBook]

我记得醋Q里的 INVALID_TARGET 好像是 -23 ？

找不到与目标QQ的关系，消息无法发送 (-23)
t/45623

cq插件发送私聊信息 报错-23
t/43230

[dynilath]

上面是说这里有个INVALID_TARGET，但是并没有在sdk其他地方用到。（看来是个有些影响的重构问题。）

[stdrc]

CQ 还有很多 undocumented 的错误码，我其实是不太想让 sdk 来维护这事的，用户应该自己去看酷Q文档和日志，否则最后问题都会变成 sdk 的问题，做了很多重复工作（

[dynilath]

类似的，我不认为要围绕酷Q作出完整支持，而是围绕用户，对用户需要的、常用部分作出一定支持。
从这个角度来看，sdk已经将酷Q接口封装，errcode对于用户其实完全看不到，这反而不能在这个角度上帮助到用户。