[Perf] Reduce allocs when parsing Program

[vicsn]

Motivation

Replaces #2516

Original PR message:

(transferred from ProvableHQ#5, and asking @d0cd for a review as suggested there)

Program parsing is something that has always been prominent in node heap profiles, and this PR targets its highest-level bits.

While parsing its components, we currently use a combination of the functions many1 and alt, which cause us to clone the parsed input at least once (more if it's not the expected component) for every component; this can be avoided by removing the use of alt in favor of a new intermediate function which is able to determine the type of the parsed component in advance and select the right parsing function without "making guesses". This is what the 1st commit does.

The 2nd commit avoids all the clones of program components that we currently perform presumably as a workaround introduced in order to be able to manage the notoriously tricky nom errors. With some refactoring (i.e. applying map_res only to potential errors), we are able to remove many allocations.

These changes reduce the number of allocations caused by the parsing of a Program in a 15-minute run of a --dev node by ~8% (an absolute decrease of over 54k allocs), making the process faster. The impact on the performance of the node as a whole depends on the number and size of the Programs it has to process.

Test Plan

CI run link

[d0cd]

@ljedrz nice find! I'd like to confirm my understanding as I'm not an expert in nom internals.
Is the first optimization avoiding this allocation?
Is the second optimization avoiding this allocation?

[d0cd]

In general, I am in favor of this PR.
I think it would be good to establish a more rigorous evaluation process for these sorts of parser changes.
For example, a regression test suite that checks against all programs deployed on-chain.

[ljedrz]

@d0cd

Is the first optimization avoiding this allocation?

It removes this use of alt, so the avoided allocation is (ultimately) this.

Is the second optimization avoiding this allocation?

This one is actually simpler; it avoids these clones in snarkVM code.

[zosorock]

@gluax had originally reviewed and approved #2516.