V2: more dev input about the sought var for each page so stories can work

[plocket]

The basic problem with index variables (or generic variables) in a Story Table is that there can be multiple rows all defining the same variable. parents[i].name.first might be Juanita for parents[0] and James for parents[1]:

| parents[i].name.first | Juanita |
| parents[i].name.first | James |

Edit for correct example:

This will work in a lot of cases, probably most, but fundamentally is impossible to find out.

Works:

target var: foo[1].bar
fields:
x.bar
x.buz

Impossible:

target var: foo[1].bar
fields:
x.bar
x[1].bar
x.buz

Is x foo or is it foo[1]?

I haven't taken the time to come up with an example situation where this would be the case, but I'm fairly confident someone will do something equivalent at some point.

That said, we now have #582 which is a possible direction to go instead.

---

[Old explanation. The below is wrong. The sought/trigger variable must be in one of the fields on the page. In the non-working example, that's not the case.]

When we get to a page that asks for the value of parents[ i ].name.first, we can't tell which value we should give. We need a unique identifier for the page that will tell us which value to use.

We have a fancy way of doing this in the most simple cases, but it doesn't scale. This works:

sought var: parents[0].child.foo
fields:
x.foo
x.bar

x is clearly parents[0].child

This does not work

sought var: parents[0].child.foo
fields:
parents[0].child.foo
x.bar

What is x? parents[0].? parents[0].child? da does not tell us this in the DOM.

The only way we can think of getting around this is to use the sought var, [or trigger var] - the one unique value on the page - to identify the right value to set for a given field. If the developer lets us know what the sought var should be for a given value, as well as the variable name that actually appears on the page (which is more complicated than you might think, but we'll go into that another time), then we can know which Story Table row is truly for which page.

This makes a fair amount more work for the developer, means that the generator can't really generate a fully working test by itself for interviews that use index variables or generic objects, and leaves us trying to write up some pretty complex instructions in some understandable way, but it is what it is.

[See PR #221 for a long and confusing discussion]