Standardise L1 block processing

[badgersrus]

Why this change is needed

https://github.com/ten-protocol/ten-internal/issues/4299

What changes were made as part of this PR

TODO

PR checks pre-merging

Please indicate below by ticking the checkbox that you have read and performed the required
PR checks

• PR checks reviewed and performed

[BedrockSquirrel]

Nice, I like the idea of preparing all the TEN-relevant block data on the host side and then passing it in with the block.

• I'd keep the guardian changes to a minimum, since this metadata will be strictly a function of the block being processed it makes more sense to be called at the blockrepository layer (and as you suggest, it sounds ideal for it to be in its own service or package).
• for HA hosts, the guardians currently fetch the L1 block from the block repository - I don't think it's worth cacheing/persisting the extracted data though unless it becomes an obvious hotspot, should be quick enough to process on demand for each guardian I guess? If it's accessed through the block repo service or similar though then cacheing would be easy to add.
• not clear to me either what's required to make this easily and robustly verifiable on the enclave side. Would definitely stub it out for the first PR though and hopefully we don't make something that's not easily provable...

[BedrockSquirrel]

Actually one other concern I had, which I think is why we started doing this enclave side to begin with is that it's easy enough to prove TEN-data was found in that block, but it's not easy to prove that the host didn't miss anything.

Maybe the incentives are such that there aren't any useful attacks there. If the host misses a x-chain msg or a sequencer-permissioning message then the enclave would get into a bricked state where it could no longer process new batches but that's not v useful as an attack I imagine.