Untangle the Interpreter type mess

[raulk]

We have to untangle the nested Interpreter design ASAP -- it is extremely unergonomic, rigid (despite generic abuse), and poorly designed. I just want to add a simple check that rejects a message if the gas fee cap is below the minimal base fee (held in state). I could check this at the FvmMessageInterpreter, because its CheckInterpreter implementation has access to FvmExecState, but it requires me to return an ExitCode, which I can't because no FVM execution is actually needed.

ChainMessageInterpreter seems like the correct nested interpreter to add this to, but it does not have access to state in its trait implementation because it inherits the generic from its inner interpreter (State == I::State), which is kinda ironic because that type is actually only ever FvmExecState in practice.

At the end of the day, what we have here is an overly generic design with, laughably, zero degrees of freedom because all interpreters are tightly coupled to one another as a result of their trait bounds restricting the associated types that the "next" interpreter must use (e.g. CheckInterpreter for SignedMessageInterpreter can only ever have an inner interpreter that uses FvmMessage as the Message type and FvmCheckRet as the Output type, which today is only FvmMessageInterpreter, and this is so restrictive, that it can never be anything else, really).