Resurrect lookup PR1263 [do not merge]

[volhovm]

This resurrects #1263 which was reverted in #1378 due to the bug that is to be understood within this PR.

Important! Note that the first commit /still/ has the bug MinaProtocol/mina#14657. It will be fixed in the following commits explicitly, so that the bug can be hunted down.

Plan before this can be re-merged:

• Resurrect the PR as it is, squashing it all into a single commit, resolve conflicts
• Check that the zero_row_zero_id still makes sense
• Explicitly revert the "colliding runtime+lookup ids" behaviour.
• Understand why the panic-within-panic bug happened in mina
• Make desired changes, confirm the bug does not reproduce anymore, cover it with a test if possible

[volhovm]

@dannywillems I confirm that the test_zero_table_zero_row test that is resurrected within this PR captures the "nonzero row with zero entry" scenario we discussed earlier. In this scenario, the error must be raised, but it is not since has_zero_entry in current master returns false positives (current resurrected PR fixes this).

For the context, the scenario could be alternatively captured by adding such a row into https://github.com/o1-labs/proof-systems/pull/1454/files#diff-30d4661dcab0b5e55e4bb6f27ea2c313bded3d2fc088df9d16f6d0fdde981cc1R603 (by either adding zero into indices, or into values, but not into both).

[dannywillems]

Please split in small PRs. Independent changes must go in different PRs and commits.

[volhovm]

Most chunks of these were merged independently. What was not resurrected is creating a private LookupTable constructor, but that affects too much code and is not very useful, so low priority.