[builtin]: support multiple prices and activations in chain spec

[niklasad1]

This PR tries to close #11014 and close #11063

To summarize the important change with this PR is that the chain spec format for builtins which support old format (with single pricing/activation) and new format as map to support multiple pricing/activations follows:

"builtin": {
    "name": "single_activation_old_format",
    "pricing": { "linear": {"base": 60, "word": 12 } },
     "activate_at": 0
}

"builtin": {
    "name": "multi_prices_and_activation",
    "pricing": {
        "4370000": {
            "info": "Hardfork X enable EIP ZZ",
            "price": {
                "linear": {
                        "base": 500,
                        "word": 0
                }
            }
        },
        "36028797018963967": { 
           "info": "Hardfork Y enable EIP ZZ", 
            "price": {
                "linear": {
                        "base": 150,
                        "word": 0
                }
            }
        }
    }     
}

[dvdplm]

Would something like this work?

"builtin": {
	"name": "single_activation",
	"pricing": {
		"linear": {"base": 60, "word": 12 }, "activate_at": 87
	}
}
"builtin": {
	"name": "multi_prices_and_activation",
	"pricing": [
		{ "linear": {"base": 60, "word": 12 }, "activate_at": 123 },
		{ "modexp": {"divisor": 3.14 }, "activate_at": 456123 }
	]
}

[niklasad1]

Would something like this work?

Yes, except the floating-point/fraction part. I'm not really sure if it makes sense to change price model on the same builtin but I guess it is more future-proof than just changing values if it is needed.

[dvdplm]

makes sense to change price model on the same builtin but I guess it is more future-proof than just changing values if it is needed.

It is most likely completely non-sensical, but yeah, the world is a crazy place!

[dvdplm]

Good stuff here, thank you for taking it on.
On the json formatting side I think we should be using hex consistently. I have some comments/questions around the new Single/Multi.

[ordian]

I'm not sure about omitting is_active check in some places, but other than that looks good.

[niklasad1]

I'm not sure about omitting is_active check in some places, but other than that looks good.

Fair enough, I can revert those to be on the safe side, however, machine calls is_active three times instead of one IIRC. I can handle that in another PR that doesn't have to be backported

[dvdplm]

minor nits

[dvdplm]

Just curious: did you measure that these #[inline]s matter or is it hunch-based optimization?

[niklasad1]

I think those were already inlined thus I didn't see any measurable difference IIRC, do you want the annotations removed?

[dvdplm]

No, it's fine, I was just curious.