iotile-sensorgraph - incorrect node_sort behavior

For example:
```
every 10 minutes
{
call 0x8000 on slot 4;
call 0x8001 on slot 4 => output 35;
call 0x8002 on slot 4 => output 33;
call 0x8003 on slot 4 => output 34;
}
```
Before toposort:
```
0 : (system input 2 always) => counter 1024 using copy_all_a
1 : (system input 3 always) => counter 1025 using copy_all_a
2 : (system input 5 always) => counter 1026 using copy_all_a
3 : (system input 6 always) => counter 1027 using copy_all_a
4 : (counter 1024 when count >= 1) => counter 1028 using copy_latest_a
5 : (counter 1028 when count == 1 && constant 1024 always) => unbuffered 1024 using call_rpc
6 : (counter 1028 when count == 1 && constant 1025 always) => output 33 using call_rpc
7 : (counter 1028 when count == 1 && constant 1026 always) => output 34 using call_rpc
8 : (counter 1028 always) => counter 1029 using copy_all_a
9 : (counter 1029 when count == 1 && constant 1027 always) => output 35 using call_rpc
10 : (counter 1024 when count >= 360) => counter 1030 using copy_latest_a
11 : (system input 0 always && counter 1030 when count == 1) => system output 0 using copy_latest_a
```

And deptree
```
{0: set([]), 1: set([]), 2: set([]), 3: set([]), 4: set([0]), 5: set([4]), 6: set([4]), 7: set([4]), 8: set([4]), 9: set([8]), 10: set([0]), 11: set([10])}
```

nodeorder =
```
[0, 1, 2, 3, 4, 10, 5, 6, 7, 8, 11, 9]
```

snippet created (i annotated the node indeces from before the toposort)
```
0: add_node "(system input 2 always) => counter 1024 using copy_all_a"
1: add_node "(system input 3 always) => counter 1025 using copy_all_a"
2: add_node "(system input 5 always) => counter 1026 using copy_all_a"
3: add_node "(system input 6 always) => counter 1027 using copy_all_a"
4: add_node "(counter 1024 when count >= 1) => counter 1028 using copy_latest_a"
10: add_node "(counter 1024 when count >= 360) => counter 1030 using copy_latest_a"
5: add_node "(counter 1028 when count == 1 && constant 1024 always) => unbuffered 1024 using call_rpc"
6: add_node "(counter 1028 when count == 1 && constant 1025 always) => output 33 using call_rpc"
7: add_node "(counter 1028 when count == 1 && constant 1026 always) => output 34 using call_rpc"
8: add_node "(counter 1028 always) => counter 1029 using copy_all_a"
11: add_node "(system input 0 always && counter 1030 when count == 1) => system output 0 using copy_latest_a"
9: add_node "(counter 1029 when count == 1 && constant 1027 always) => output 35 using call_rpc"
```

Nodes if i do inspect_nodes sequentially in coretools
```
0: (system input 2 always) => counter 1024 using copy_all_a
1: (system input 3 always) => counter 1025 using copy_all_a
2: (system input 5 always) => counter 1026 using copy_all_a
3: (system input 6 always) => counter 1027 using copy_all_a
11: (system input 0 always && counter 1030 when count == 1) => system output 0 using copy_latest_a
10: (counter 1024 when count >= 360) => counter 1030 using copy_latest_a
5: (counter 1028 when count == 1 && constant 1024 always) => unbuffered 1024 using call_rpc
6: (counter 1028 when count == 1 && constant 1025 always) => output 33 using call_rpc
7: (counter 1028 when count == 1 && constant 1026 always) => output 34 using call_rpc
8: (counter 1028 always) => counter 1029 using copy_all_a
4: (counter 1024 when count >= 1) => counter 1028 using copy_latest_a
9: (counter 1029 when count == 1 && constant 1027 always) => output 35 using call_rpc
```

It looks like the order of the nodes changes from the snippet to getting programmed. It went from

[0, 1, 2, 3, 4, 10, 5, 6, 7, 8, 11, 9] to
[0, 1, 2, 3, 11, 10, 5, 6, 7, 8, 4, 9].

Looks like node 11 and 4 switched places. This reordering occurs immediately after the add_node command is called.