Integrate new CosetEvals type

[jtraglia]

This PR renames Cell to CosetEvals and adds a new Cell type which is a flat array of bytes, like Blob. The old Cell type was an abstraction leak (leaking BLS field elements) & the input bytes-representation wasn't a flat array of bytes; it was Vector[Bytes32, FIELD_ELEMENTS_PER_CELL] which is difficult to work with.

[asn-d6]

Hmm, I'm not a huge fan of CellBytes as a name, especially if it's input/output to public methods. This can be seen in functions like compute_cells_and_proofs() or compute_cells() where they output CellBytes even though the naming implies Cell.

I agree with Justin that ideally we would make Cell a flat array of bytes (like Blob) that is used in public methods, and then figure out how to handle the internal Fr representation that is never exposed to the world (like Polynomial).

With regards to the internal Fr representation, our job here seems harder than the Blob -> Polynomial naming in 4844. I guess an accurate naming could be Cell -> CosetEvals but this might create more confusion than help (altho it might help us create a better narrative around cosets in the codebase).

Another (IMO worse) approach is to just handle the internal Fr representation with an untyped Sequence[BLSFieldElement] which is already what verify_kzg_proof_multi_impl() and compute_kzg_proof_multi_impl() are doing, even though they should be handling Cell.

[kevaundray]

Yeah I think the naming can be improved, approved because we can iterate, and the important thing in this PR is removing internal cryptography types from the API

[asn-d6]

There are still a few issues around the PR. I'm fine with merging it as is, and iterating it on it, if you feel that's the right move.

[asn-d6]

Something wrong here with the function wants to return an evaluation domain but we are returning CosetEvals

[asn-d6]

Pushed bc607ec in an attempt to clarify things

[jtraglia]

Can't approve my own PR. But this LGTM, thanks for the help guys!

[asn-d6]

LGTM! Thanks all!