core/vm/program: create evm programming utility

[holiman]

In many cases, we have a need to create somewhat nontrivial bytecode. A recent example is the verkle statetests, where we want a CREATE2- op to create a contract, which can then be invoked, and when invoked does a selfdestruct-to-self.

It is overkill to go full solidity, but it is also a bit tricky do assemble this by concatenating bytes. This PR takes an approach that I've been using in goevmlab for several years.

Using this utility, the case can be expressed as:

	// Some runtime code
	runtime := program.New().Ops(vm.ADDRESS, vm.SELFDESTRUCT).Bytecode()
	// A constructor returning the runtime code
	initcode := program.New().ReturnData(runtime).Bytecode()
	// A factory invoking the constructor
	outer := program.New().Create2AndCall(initcode, nil).Bytecode()

We have a lot of places in the codebase where we concatenate bytes, cast from vm.OpCode . If we use this approach, we can make those places a bit more maintainable/robust.

WDYT?

Note: I could have just added a dependency to goevmlab Program. However, goevmlab depends on go-ethereum, and I'd rather just avoid the potential cycle problems.

[MariusVanDerWijden]

I like this very much, I've been using goevmlab.Program for a few years in a bunch of scenarios for reproducing and writing tests. Moving this upstream would also allow me to get rid of the goevmlab dependencies in FuzzyVM and make the dependency mgmt in case of a hardfork much easier

[karalabe]

As long as we're not promising API stability and are willing to massively iterate on this if needed, I'm happy about it.

[holiman]

not promising API stability and are willing to massively iterate on this if needed

Yeah, definitely. We should make it explicit, though. I'll add some documentation to that effect

[MariusVanDerWijden]

lint failed

[lightclient]

Generally like this a lot.