Pexe inspect plan fixes

[robknight]

Closes #222

Fixes pexe inspect so that instead of using the low-level Podlang predicates, it uses the high-level Rhai AST to infer information about object/action structure. This is used for:

• pexe inspect plan - explains how a real transaction proof for a given action would be built, e.g. which statements it uses and how many PODs
• pexe inspect prove - generates a real proof from mock data
• pexe inspect classes - lists classes and their fields and constraints (where possible to infer)

This previously worked for the limited examples we had, but worked much less well for the larger microverse example, with panics and excessive memory usage. Switching to the more reliable source of information about the actions/classes solves the issue.

[ed255]

I have some questions about the idea behind the feature that gathers requirements.

[ed255]

why is this a set and not a single value?

[ed255]

Why declare Pin instead of using Value?

[ed255]

There's min but not max.

I would like to have a discussion about the idea behind this representation, and what's the future plan for this requirements feature.

Technically we could just show the list of predicates and that would show the requirements. But I guess here you're aiming for something more readable?
Is the goal to capture as much as you can but not everything here?
For example, if we have a lt statement you can fill in the min value. But if we have something likea = 2*b, would you store that in a FieldFact for a? Or the goal is never to be exhaustive?

[ed255]

Here's a summary of what I discussed in yesterdays call:
In general I think the inspect functionality is nice and useful, so I'm in favor of keeping it.
One of the features is to report requirements around actions, which is mostly implemented in the requirements.rs file now (previously the same feature set was implemented in another file). The way it is implemented seems a bit complicated to me: until now he had a language to express requirements, which is the statement templates (sets of statements that have wildcards + literals as arguments). This file implements a new shape to define requirements and I find it complex because

• It doesn't use the "statement template" language, and instead it introduces a new custom language to express observed requirements or constraints.
• It needs to be extended to cover more information: for example now there's min but no max
• I believe it can never be complete, because it's too simple. It can express relations to constants but not relations to variables.

For this reason I would suggest removing this "custom language" for requirements. This includes FieldFacts, ObjectIdentity, FieldWrites and other types as well as associated functions to collect this information. Instead I suggest following a simpler approach that would convey the same information albeit in a less easy-digestible way: build a map from object fields to the list of statement templates that constrain them and display that as facts.