Allow entities allocation to consider sibling and/or descendant hierarchies

[lindsay-stevens]

In #827 this review feedback noted a case where pyxform produces an error (ENTITY_009 / unsolvable meta/entity topology) where it instead should be possible to allocate the entities to sibling containers. In other words, valid candidate container g1 is depth=2, valid candidate candidate container g2 is depth=2, but only g1 (or it's ancestors) may be considered by e1.

| survey |
| | type          | name | label | save_to |
| | begin_repeat  | r1   | R1    |         |
| |   begin_group | g1   | G1    |         | e1
| |     text      | q1   | Q1    | e2#e2p1 |
| |     text      | q2   | Q2    |         |
| |   end_group   |      |       |         |
| |   begin_group | g2   | G2    |         |
| |     text      | q3   | Q3    |         |
| |   end_group   |      |       |         |
| | end_repeat    |      |       |         |

| entities |
| | list_name | label                       |
| | e1        | concat(${q1}, ${q2}, ${q3}) |
| | e2        | E2                          |

The above case can be resolved by moving e2 to row 2 and moving e1 to row 3. Or equivalently, if pyxform were to revert to prioritising entities with save_to references over those without. However, neither approach works if the ancestor hierarchy is saturated e.g. 3x entities with the label concat(${q1}, ${q2}, ${q3}) - this would place the first two entities in r1 and g1 but fail to see that g2 is also available for the third entity. There are probably other examples with save_to only, and it doesn't necessarily require full saturation (e.g. there could be more containers in r1 or under g1 or g2).

It may be possible to address this by:

• have get_allocation_request find/validate/propose all valid paths in the request instead of just one. For variable references, these paths could include containers that are deeper than any of the reference targets.
• have allocate_entities_to_containers try each valid path, possibly depth first (e.g. path 1 depth 3, path 2 depth 3, path 1 depth 2, path 2 depth 2, etc; rather than path 1 depth 3, path 1 depth 2, path 2 depth 3, path 2 depth 2, etc).
• the siblings case seems easier to address than descendants but it might make sense to do both at the same time.

In the meantime the workaround would likely be to use calculate items to copy values into container(s) so that the references aren't spread over sibling hierarchies.

[lognaturel]

Thanks for filing! I see how it's not straightforward to address generally. I don't think it affects likely common form shapes so it feels ok to leave open to have a record of it and not prioritize now.