experimental: transaction ordering policy

[tynes]

Description

Explore what applying a predicate to the inputs as part of the
derivation pipeline would look like. The predicate is defined
using evm bytecode and can therefore be quite flexible based
on the chain operator's needs. The payload is dropped if the
predicate returns false.

The chain operator can configure the predicate's bytecode
on L1 using the system config contract.

In practice, this allows for static analysis of the ExecutionPayload
before execution. If some chain operator defined invariant
about the ExecutionPayload isn't held to be true, then
the payload is dropped. This can be used to enforce constraints
on the way that block builders can build blocks.

[tynes]

It would be good to have a view function on the contract or in another predeploy that accepts a block body and returns a bool if the block is valid or not. This will help block builders to know they are creating valid blocks

[tynes]

For this to work with deposits, dropped blocks would need to be mapped to deposits only blocks per ethereum-optimism/design-docs#20

[emhane]

Suggested change

	The L1 Attributes transaction is assumed to be updated with a [diff based serialization](https://github.com/ethereum-optimism/specs/pulls/13).
	The L1 Attributes transaction is assumed to be updated with a [diff based serialization](https://github.com/ethereum-optimism/specs/pull/13).