feat: 为状态机增加获取targetState、targetStateChain功能

[benym]

虽然状态机在内部DSL维护了状态转移规则，但在实际使用过程中
发现不能够通过当前状态+事件获取到后续可能转移到的状态，DSL转移过程除UML图外不支持代码获取

比如场景

正向状态，待审核->业务审核通过->商务审核通过->法务审核通过

反向状态，待审核->业务审核驳回
待审核->业务审核通过->商务审核驳回
待审核->业务审核通过->商务审核通过->法务审核驳回

事件是审核通过、审核拒绝
在这个场景中通过待审核初始状态+审核通过事件，能够走到正向链路的最后，这条链路可能是需要展示出去的

更加通用的情况是：
通过当前状态+事件获取后续节点，或后续状态链
如果单独再维护一套等价于DSL转移过程的代码显得有点烦琐
除此之外也为了增加代码维度对后续状态获取的透明度，当状态机状态较多时提升状态链路可预测性

基于上述情况
新增4个功能

1. com.alibaba.cola.statemachine.StateMachine#getTargetStates，支持从当前状态+事件获取DSL中下一跳状态
2. com.alibaba.cola.statemachine.StateMachine#getTargetStateChain，支持从当前状态+事件获取DSL中的状态链，全面考虑现有internalTransition、externalTransition、externalTransitions、externalParallelTransition链路内部转化，一对一串行，一对多，多对一，环形链路等情况
3. com.alibaba.cola.statemachine.StateChain#showStateChain，支持状态链的控制台打印可视化
4. com.alibaba.cola.statemachine.StateChain#generatePlantUml，支持状态链PlantUml可视化

对应单元测试
com.alibaba.cola.test.StateChainTest

具体示例
给定如下状态机

获取初始状态为STATE1, 事件为EVENT1的，状态链为

[CLAassistant]

All committers have signed the CLA.

[LeePui]

老哥，看你的状态描述和我的有点类似。我想咨询个问题，你上面说的：

比如场景
正向状态，待审核->业务审核通过->商务审核通过->法务审核通过
反向状态，待审核->业务审核驳回
待审核->业务审核通过->商务审核驳回
待审核->业务审核通过->商务审核通过->法务审核驳回
事件是审核通过、审核拒绝
在这个场景中通过待审核初始状态+审核通过事件，能够走到正向链路的最后，这条链路可能是需要展示出去的

• 你这里只有两个事件：审核通过, 审核拒绝。按理说是不是还应该有一个开始审核事件，开始审核后，对象状态为审核中，然后经过审核，状态有可能变为：审核通过/审核拒绝。
• 假设是这样的话，那么结合COLA状态机，要怎么设计这个流程的代码呢？
• 假设审核是一个接口方法：

// 对xxx文件进行审核的业务逻辑
booleab examine(xxx) {
    // 文件进入审核中状态
   // 开始审核
   if 某某条件: 
        审核通过：修改数据库文件状态，打印日志，发送文件审核通过消息
        触发stateMachine.fireEvent(审核通过)
    else:
        审核拒绝：修改数据库文件状态，打印日志，发送文件审核通过消息，发送手机短信告知
        触发stateMachine.fireEvent(审核拒绝)
}

• 那么我想咨询下，在审核通过/审核拒绝的逻辑中，例如修改数据库文件状态，打印日志，发送文件审核通过消息，这些操作应该放到状态机对应的事件action里面去做，还是在examine方法里面做呢？
  • 假设在examine方法里面做，那触发stateMachine.fireEvent(审核通过)感觉就没啥用了
  • 假设在状态机对应的事件action里面去做，那么哪些应该在action里面做？哪些应该在examine方法里面做呢？
  • 想请教下你那边是怎么设计的