Witness generation for block machines connected via permutations

[georgwiese]

Fixes #1074

This PR introduces the following changes:

• Changes to machine detection so that block machines that are connected via permutations are also detected. This is a bit tricky, because it's not as obvious which column is the latch column, as it's not necessarily used in the RHS permutation selector expression.
• In Processor::process_outer_query(), we make sure that the selectors in the latch row are set to 1. This does nothing if the selector is a fixed column, but if it is a witness column, it would be set to 1.
• For the dummy block, we need to make sure that the selectors are set to 0. Furthermore, other cells in the block might depend on the selector value (see [Prototype] Machines communicating through shared memory #1071 for a working example). We do this by:
  • Setting all selectors to 0 in the latch row
  • Running the full block processor to determine other cells which depend on the selector value
  • As before, we fill unknown cells with values of the first real block

[georgwiese]

Turns a panic into an error. This happens in the block_lookup_or_permutation test:

• A block is computed by a permutation using selector2
• A loop is detected
• When checking the next identity using selector1, process_link() on the last row. But selector1 is unknown at this point.
• The error is caught by the loop detection code and the executor reverts to the normal solving algorithm.