Make witin_namespace_map more robust

[matthiasgoergens]

Earlier, we cached the length of witin_namespace_map and fixed_namespace_map inside the CircuitBuilder. That means we had to manually keep the cache in sync with the underlying source of truth.

In this PR, we remove the caches and instead ask for the lengths when we need them.

This makes our logic simpler and more robust: fewer moving parts that can go out of sync.

Git agrees:

20 files changed, 84 insertions(+), 134 deletions(-)

For context, this PR prepares for removing the need to clone our Expressions.

[hero78119]

In almost all the case, unifying source of truth and less error prune make much sense!
But in this case I will say not.

We expect ConstraintSystem

ceno/ceno_zkvm/src/circuit_builder.rs

Line 82 in 79bb73b

pub struct ConstraintSystem<E: ExtensionField> {

to be serialized into proving/verifying key. So, we expect some fields scope should be move to cfg[test] or just under some feature flag toggle on
All the "xxxxx_map" fields is one of the example. Those debug info are

1. from prover perspective, only push those name strings in non-release build. Those variable debug name shouldn't be in release build nor in binary.
2. from verifier perspective, neither debug nor release need this information, so they should have them "serde skip".

With above 2 points, I will say this PR change is unnessesary, because source of truth shouldn't reverse release info to depends on debug info

[matthiasgoergens]

@hero78119 Could you please add that reasoning as a comment in the code? And perhaps make it so that witin_namespace_map actually only show up in debug mode? (Or otherwise leave a TODO-comment to that effect?)

Btw, I don't think we should spend effort removing variable names from a release build. It's better to leave them around for debugging, because things can go wrong with the release build, too.

(That's all assuming that constructing the circuit is far from the most expensive thing we are doing. I expect (recursive) proving to take the majority of the runtime.)

[...] to be serialized into proving/verifying key.

You can do that, even with the change I suggested here. You would keep a Vector in memory, but serialise just it's length. Deserialisation would read the number and produce dummy entries for the vector.