Consider adding an API that enables application circuits to be built across both fields

[str4d]

The user-facing API in #251 focuses on a single-field circuit, which is much easier for crate users to reason about (as they don't need to handle deferreds, or the way that the relative field sizes flip between circuits).

There may be some subset of users who want to create more advanced circuits that leverage both fields. Once we've implemented both the user-facing API and the recursive circuit, we should have a better idea of how these users might most easily build such circuits.

An API for this use case could even be useful for implementing the recursive circuits themselves, so we might want to think about this while writing them. But this issue does not block either the main user-facing API, or the recursive circuit implementation; it would be a secondary API targeted at advanced users.

[nikkolasg]

Bumping this issue because a relevant work has been out recently CurveTree (paper). This accumulator would fit perfectly inside Halo2 proof system assuming we can:

1. inject user defined polynomials in the recursion verifier gadget
2. define operation accross both fields (what CurveTree relies on)

With this, there would be almost no user circuit facing to develop to open positions using curve tree (in its simplest form probably, if we don't care about zk) and we'd just rely on Halo2 perfs (instead of how skilled we are to write circuits ;) )

I think 1. is on the longterm roadmap somewhere but just in case I wanted to give an extra justification of why both features may be really useful.