Expand graph cycles to include self-referential nodes

[garethbowen]

In #891 we introduced detection of graph cycles based on how JavaRosa does it, which is great. However it misses the case where a field refers to itself, supposedly because JR isn't reactive in the same way as WF so the calculation only fires once. However this is still an invalid form with an undefined behaviour, so the fact that JR handles it is more luck rather than good design.

A simple example, exercised in this test, is...

<bind nodeset="/data/group/a" type="int" calculate="../a + 1" />

In WF this causes an infinite loop. In JR this only appends a single "1" after the user input is complete (not tested).

A more complicated example is #909 where an itemlist updates from its own selection. The solution for this one was to catch 100 iterations and silently stop updating.

Currently we have three different approaches.

1. Forms with cycles break while filling questions #891 rejects the form on load in both WF and JR.
2. The simple example above loops for ages then rejects form load on WF, but loads on JR.
3. Crash after clicking on a checkbox #909 loads the form on both WF and JR.

Figure out the right approach and apply this to all three examples, to standardise the code and user experience.

[garethbowen]

My opinion is a cycle is a bug in the form and WF should show a fatal error on form load with a helpful error message (option 1 above). This may cause problems with forms that currently work in Collect but it's helpful to surface issues in forms even if Collect handles them. I don't think the behaviour is defined in the spec so what Collect is doing may not match what the form designer wanted anyway.

Also as a significant use case for WF is to preview the form during form development, showing these errors early is preferable to silently ignoring them. We could consider adding some sort of strict or dev mode for use in preview mode, but that's complicated and likely lead to confusion about why a form works in one mode and not another.