例行提交

修复了一端短时间连续发送时，另一端只收一次的bug.
游戏逻辑写到了开局洗完牌发牌完成后的阶段。
增加了Packer类,主要用于联系Server和游戏逻辑，使游戏逻辑跟消息收发独立。
定义了一个生成随机序列的模板函数，目前在洗牌和分配阵营时有使用 。
定义了多层状态管理机制，未完成。
----------------------我是分割线---------------------------
我解释下多层状态管理机制【原创】:
我感觉一个游戏可能的状态真的太多了，要枚举出来难度太高，也不好管理，所以就模仿函数的调用的压栈机制，改成异步，来做这个状态管理机制。
StateManager类管理状态，里面封装了一个栈，所有时候只能对栈顶的状态进行处理，定义了对状态的三种基本操作：
NEXT:进入下一个状态。
CALL:当前状态压栈,进入一个新状态。
RETURN:弹栈,弹出当前状态,回到弹栈之后的栈顶的状态。
这些操作会在执行时发出信号，以便添加自己的处理。
目标是这些操作可以随意组合。下面是例子：

最底层状态：的状态表示当前是哪个玩家的回合，NEXT操作会转到下一个玩家回合，最后一个玩家的回合NEXT会转到第一个玩家回合。创建时会CALL第一个玩家的玩家回合状态，玩家回合状态的RETURN会触发最底层的NEXT,NEXT会又触发CALL新玩家的回合状态。

玩家回合状态：比如准备阶段，摸牌阶段行动阶段等，然后攻击或者技能之类的会CALL更高层的状态。最后一个状态下的NEXT操作会直接触发RETURN操作

攻击响应状态：这种状态可以方便地移交控制权，比如在0号玩家的回合0攻击1后，1必须响应，这时应吧控制权从0交给1，那么在0的玩家回合状态下可以CALL玩家1的攻击响应状态，Rule类通过StateManager只看得见顶层状态的控制权在1手上，很好处理，如果1响应还要攻击玩家2，那么在1的攻击响应状态下再CALL玩家2的攻击响应状态就行了。当结算完成后RETURN回去后控制权也就交了回去。

伤害结算状态：这种状态理论上根本不用玩家控制，但鉴于各种技能的存在，伤害结算是个庞大的工程，甚至有的角色能在这阶段获得控制权，所以我觉得也应该有这个状态方便Rule管理。

等等等等

目前构思是这样，但内存管理似乎有点问题，有个指针不知道该什么时候delete。。有可能会改实现方式。