Convert verbatim into a single builtin with literal arguments

[cameel]

Abstract

Currently we have a separate verbatim_<n>i_<m>o(c) builtin for every combination of n and m. We should replace it with a single verbatim() builtin with all arguments being literal arguments.

Motivation

The current design complicates the implementation, because it has to be treated specially. Internally all other builtins always exist, while verbatim ones are generated on demand. This became problematic especially after #15520, because it makes it harder to give them fixed locations in an array. We rely on the fact that we can't have more than 10000 of them (m and n are limited to 99), but the limit is artificial and we're even considering lifting it eventually.

Yul builtins can have literal arguments - arguments that must always be literals, not variables or expressions, so that their values are known at compilation time. Such arguments can be used for m and n instead. This seems much simpler both for the implementation and for the user.

It's actually not clear to me why we went with the original design in the first place. The issue (#10869) did not mention it, while the PR (#11123) used it from the beginning. The other argument already is a literal argument so that option must have been considered. We could not come up with a good reason the last time we discussed it and it seems that there are no significant obstacles to changing it to work that way.

Open design questions

• Should we keep the old names reserved or release them?

Specification

• Remove verbatim_<n>i_<m>o(c) builtins.
• Define the equivalent verbatim(n, m, c) builtin:
  • Mark all arguments as literal arguments.
  • Keep the range restrictions for now.
• Update the docs.

Backwards Compatibility

This is a breaking change for Yul. Solidity and assembly import are unaffected, because verbatim is not available in inline assembly.

Due to not being available in inline assembly verbatim() does not seem widely used. We decided it does not need a deprecation period. We'll swap one version for another in a breaking release.