Add Rescue Prime as a hash function option for prover/verifier about winterfell

[Nashtare]

Ideally I think we would like to abstract it behind a single RescuePrime additional type in the HashFunction enum. In crypto/src/hash/, we could then have a single pub struct RescuePrime<B: StarkField>(PhantomData<B>); defined, in addition to the existing sha3 and blake3 hash functions, which relies internally on the concrete implementation of Rescue for the given field.
This would require implementing a Rescue instantiation (of same conjectured security) for each existing field in math/src/field (currently f128 missing) but would then allow for an easier abstraction on the prover / verifier side. However I think we would still need a generic implementation, which without #![feature(specialization)] is not allowed. I don't know of a way to deal with this on the stable channel.

[irakliyk]

One thing I'm wonder is whether we should make hash function a generic parameter for prover/verifier. This way, users of the library would be able to provide any hash function implementations which comply with ElementHasher interface.

I think on the prover side this shouldn't be too difficult to do. But the verifier side might be more challenging (depending on how sophisticated we want to make it).

[irakliyk]

A few more thoughts on this.

On the prover side, there are a couple of options:
We could add something like HashFn associated type to the Prover trait:

type HashFn: ElementHasher<BaseField = Self::BaseField>;

Another option is to make Prover trait generic:

trait Foo<H: ElementHasher<BaseField = Self::BaseField>>

I probably prefer the former approach as I think it would be more flexible - but open to suggestions.

On the verifier side, we'll need to update the signature of the verify() function to look something like this:

pub fn verify<AIR: Air, H: ElementHasher<BaseField = AIR::BaseField>>(
    proof: StarkProof,
    pub_inputs: AIR::PublicInputs,
) -> Result<(), VerifierError>

The above would mean that if we specified hash function incorrectly for a given proof, proof verification will fail. We might want to return a meaningful error message for this - but I'm not sure yet what's the best option for detecting this error.

In general, we'll also need to remove HashFunction enum and update the proof struct accordingly (i.e., the proof won't track which hash function was used to generate it - or at least not via this enum).

[Nashtare]

Out of the two options above, I'd also prefer the first one. Although I did appreciate the customization left to the user to specify the targeted hash function. Also removing the Hash function from the proof options would require changes or fixing assumptions on the hash functions supported when evaluating the security level, as this is a method of the Air trait.

[irakliyk]

Closed by #111