Add a new ScalarMap struct and use it to make witnesses more structured

[nategraf]

At the moment, witnesses are provided as Vec<G::Scalar>. As a result, the building of witness must recreate the exact of the allocation of scalar vars. Additionally, this makes it difficult to ever work with variable references that are not exactly the index assigned as the ordered in which variables are created.

This PR attempts to refactor this such that assignment of variables, including construction of a witness, is done by associating a ScalarVar with its assignments (e.g. nizk.prove_batchable([(x_var, x), (y_var, y)], &mut OsRng)). This is as opposed to the witness always being a Vec where the order determined which scalars are assigned to which variable (e.g. nizk.prove_batchable([x, y)], &mut OsRng)).

[nategraf]

I marked this PR as draft as I am not entirely happy with the examples, and would like to look at this again in the next couple of days and see if I can improve on the "user"-facing API. I intend to look at the crates using this library and seeing how big of a breaking change this will be to them as well.

[mmaker]

Fantastic, thank you so much! I think we have to start committing to semantic versioning, so we'd have to change the function name for this new API and deprecate the old one. Shouldn't be too much work. The PR should be linted too.

[nategraf]

As I've been working on the examples, I'm convinced that we need some updates to the way composed relations work with instance and witness assignments to make this work well. I am working on a proposal for that, and am implementing this all at once rather than one piece at a time so that we only need to propagate the breaking changes once.

[nategraf]

I think we have to start committing to semantic versioning, so we'd have to change the function name for this new API and deprecate the old one. Shouldn't be too much work. The PR should be linted too.

Why is that? With semantic versioning a version bump from 0.1 to 0.2 can include breaking changes. Cargo will also not update automatically, so the breakage should only happen when the consumer updates their Cargo.toml. I am also interested in helping make PRs to the consuming libraries when we decide to land this to ease the update.

[mmaker]

@nategraf thank you so much! Yes, you're right, let's just keep in mind that this needs to go in 0.2