Add foreign call definitions into ABI.

[TomAFrench]

I've thought that we should add this for a while but this is shown by #4959.

We currently don't store any info for the oracle calls which a circuit will make in the ABI which prevents us from automatically ABI encoding/decoding arguments/return values. Having this information would also allow us to throw better errors when trying to resolve an oracle call which needs a response when there is no resolver for it.

During compilation we should keep track of all the oracle calls which the program may make and add these to the ABI.

[TomAFrench]

Once this is done we can also replace the name of the oracle call which is stored in the byte code with just an identifier.

[asterite]

I bumped into an issue. Every program has this oracle:

#[oracle(print)]
unconstrained fn print_oracle<T>(with_newline: bool, input: T) {}

but when I try generating its ABI I get this error:

entered unreachable code: T cannot be used in the abi

There are also these oracles in Aztec-Packages that have generic types:

#[oracle(getAuthWitness)]
unconstrained fn get_auth_witness_oracle<let N: u32>(_message_hash: Field) -> [Field; N] {}

#[oracle(avmOpcodeCalldataCopy)]
unconstrained fn calldata_copy_opcode<let N: u32>(cdoffset: u32, copy_size: u32) -> [Field; N] {}

#[oracle(avmOpcodeReturn)]
unconstrained fn return_opcode<let N: u32>(returndata: [Field; N]) {}

#[oracle(packArgumentsArray)]
unconstrained fn pack_arguments_array_oracle<let N: u32>(_args: [Field; N]) -> Field {}

and maybe others...

How do we handle those?

[TomAFrench]

Oof, yeah this is a bit unfortunate. We'd have to generate the ABIs for the monomorphized variants of these functions instead so generate for the function avmOpcodeCalldataCopy<10> or something.

[TomAFrench]

hmmm, this would get be a pretty breaking change however and would screw up aztec's handling of oracle calls a lot.