feat: introduce program in noir_js

[kobyhallx]

Description

Problem*

Resolves

Summary*

Documentation

• This PR requires documentation updates when merged.

  • I will submit a noir-lang/docs PR.
  • I will request for and support Dev Rel's help in documenting this PR.

Additional Context

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[kevaundray]

Lets split this into two PRs -- the first one will introduce Create a new PR with master and not ignore the build artifacts

We then modify noir-starter so that it works in CI with that commit, then work on making noir-starter work with the program API

[kevaundray]

Noting that this has changed from #2856

[signorecello]

Did we end up with this naming? I kind of like @Savio-Sou suggestion of "intermediate proof" and "final proof" as it sound more descriptive

[kobyhallx]

Does that make sense in case where you are not doing recursion?

[Savio-Sou]

Does that make sense in case where you are not doing recursion?

The user would stick with generateFinalProof then. Not the cleanest but not the most unintuitive (while more intuitive than generateProof for recursion users, which could be a big group of devs as recursion would be needed for any fairly complex programs running in browsers.)

[socket-security]

New and removed dependencies detected. Learn more about Socket for GitHub ↗︎

Packages	Version	New capabilities	Transitives	Size	Publisher
typescript	5.1.5	None	+0	40.1 MB	typescript-bot

🚮 Removed packages: @aztec/bb.js@0.7.2

[Savio-Sou]

Resolves #2835?

[kobyhallx]

Does that make sense in case where you are not doing recursion?

The user would stick with generateFinalProof then. Not the cleanest but not the most unintuitive (while more intuitive than generateProof for recursion users, which could be a big group of devs as recursion would be needed for any fairly complex programs running in browsers.)

What's the cleanest? So when creating regular proof what's the meaning of final in generateFinalProof? Is this suggesting me then that I have missed some step on the way? Sure generateFinalProof makes sense in context of recursive processing but on non-recursive is misleading.

For purpose of easier imagination should we adopt reference to something, like processing a tree? where there might be parent - child relationship?

final and intermediate are little misleading imo.

[Savio-Sou]

What's the cleanest?

For non-recursion devs, nothing beats just generateProof.
Proving with generateFinalProof and generateParentProof sounds equally unintuitive to me if I'm not expecting an intermediate or child.

To get the best of both worlds, we could have generateFinalProof as a syntactic sugar of generateProof.
That way non-recursion devs would simply deal with generateProof, while recursion devs learn and code with generateIntermediateProof and generateFinalProof.