feat: new integration API

[jonathanpwang]

The origins of the design are in this wip note: https://hackmd.io/TKbiV5rwSQGB8-XxItUS2A

The API still has Adapter vs Core, where there is a separately of the row slice between the two. However we now opt to give more control flow to CoreChip, so it can directly access VM state and use the results locally via several notions of transactions:

• a transaction is for the lifetime of a single instruction processing (currrently only for single row)
• by nature of zkVMs, there must be 3 kinds of transactions: AIR, execute, trace for constraints, runtime, trace generation respectively.

All namings are up for debate/revision.

Differences to the old API:

• the width of adapter row is not statically determined, to provide more flexibility in usage
• an adapter transaction keeps some internal state to help manage timestamps but it is stateless from the chip perspective (it will not store any records). The transactions returns all information to the Core and it is the responsibility of Core to store any records needed by adapter.
• if you use adapter, timestamps should mostly be managed for you.
• just one struct that implements both VmAdapterChip and VmAdapterAir.

I provide some traits for transactions, which is the interface for Core chips that need to be re-used for different adapters. But my perspective is that actually most of our Core chips (with exception of ALU) don't really need to have generic adapters. So I've shown how to do the generic version for BaseAlu, but for most Core chips I envision that we can implement everything for a specific adapter, which will make life a lot easier. The framework is also flexible that you can always introduce new traits when needed if you want to expose additional interfaces from the adapter transaction (the MaybeRead for immediate handling is an example of this).

My todos:

• a new prank test adapter is needed for negative tests
• implement Rv32VecHeapAdapter to make sure the Alu works for bigint

Working thoughts on Rv32VecHeapAdapter:

• implement MaybeRead but where it only handles the case of address space != 0. Address spaces will be hardcoded to 1,2 which means sometimes ignoring the address.address_space passed in.
• in AirTx::end, it will override the operand.e value to always be 2 (I couldn't think of a better interface so far)

Working thoughts on other Rv32IM core chips:

• I think everything except loadstore should be able to just use the Rv32RegisterAdapter
• For loadstore, we can make some more custom Adapter that wraps Rv32RegisterAdapter and provides address space 2 memory access operations. This does not need to implement the various Adapter / Tx traits, because the core chip should just be specialized to this custom adapter.

[github-actions]

group	app.proof_time_ms	app.cycles	app.cells_used	leaf.proof_time_ms	leaf.cycles	leaf.cells_used
verify_fibair	(-59 [-2.5%]) 2,315	513,309	19,357,682	-	-	-
fibonacci_program	(-87 [-1.4%]) 6,096	1,500,137	51,487,838	-	-	-
regex_program	(+711 [+4.0%]) 18,674	4,190,904	165,010,909	-	-	-
ecrecover_program	(+53 [+2.1%]) 2,628	285,401	15,075,033	-	-	-

Commit: 62bcb5d

Benchmark Workflow