节点逻辑重构
在这次重构中，我们不需要改UI部分，而是聚焦于node manager对node的指令的控制和node的行为的表现。我打算把系统运行的控制权集中在manager上，使用类似生命周期的方式控制节点指令。
逻辑流程：每个node都有一个status为ready hang或complete，刚开始启动的时候，所有的都为ready或者complete，然后启动start节点。
Manager拥有一个触发表，在开始一次周期前，将触发表并入运行时表中，并清空触发表。
在周期中遍历运行时表运行节点内置的loop方法 收集下一次的触发以及要从运行时表中去除的东西。
节点不再传递值，会从前面的节点拿取值或者引用，启动后每周期检查如果前方的节点不处于complete，那么status就改为hang，将自己维持在运行时表中，并且将前面的node加入触发表，取值满足后进行运算返回complete。
特殊节点：变量节点不存在hang，在启动之后立刻返回值或者引用，并且complete，这些节点拥有一个signal输入，这个输入通常不需要连接，只有在循环节点内，这个signal才用得到。
循环和子函数节点：可能需要一种新的状态，表示其内部正在运行。这些节点可能需要一个新的UI控件，比如一个rect，当别的节点拖放在这个rect里面，就相当于在节点内。（我们的UI支持自动调整，你只需要在之前放选项的地方，也就是UI builder所需要的地方直接加入一个可以手动放大缩小范围的rect，并且对他添加脚本就好，而像for循环原有的每个循环都会有的Index和Signal输出点就可能不用放在第三列，而是放在位于输入节点的第一列，以拉取到rect里面）循环还包含一个子控制器监控里面的节点运行情况，不过这里面节点的运行状况依然交由主manager子控制器只负责检查是否完成，重置节点并开启下一步的循环。
子函数节点包含子函数定义节点和子函数执行节点。定义值点只有一个输入：string name，我们使用rect外连接到rect内的变量节点代表输入，以及连接到rect外的set节点代表输出。
Manager可能需要扫描所有文件，注册这些子函数定义节点，然后在其他地方的执行节点中表现为input输入和output输出。
关于signal：Signal依然存在，仅用于触发操作，拥有signal并且signal输入已连接的节点会像上文一样等待signal。
其他：节点拥有一个“到stars节点的最短距离”l
举例：L等于零的输出可以接在l等于七的输入上，而l等于七的输出不能接在l等于二的输入上。确保单向逻辑。
关于引用和动态类型：比如set节点，输入第一项为原值，比如一个变量int。第二项也为int，用于更改第一个项指向的值。引用节点没有输出，只有输入，并且要根据输入的第一项的类型更改输入第二项的类型，可能要为此实现一个input<any>之类的东西，