GH-98831: Add DECREF_INPUTS(), expanding to DECREF() each stack input

[gvanrossum]

The presence of this macro indicates that a particular instruction may be considered for conversion to a register-based format (see faster-cpython/ideas#485).

An invariant (currently unchecked) is that DEOPT_IF() may only occur before DECREF_INPUTS(), and ERROR_IF() may only occur after it. One reason not to check this is that there are a few places where we insert two DECREF_INPUTS() calls, in different branches of the code. The invariant checking would have to be able to do some flow control analysis to understand this.

Note that many instructions, especially specialized ones, can't be converted to use this macro straightforwardly. This is because the generator currently only generates plain Py_DECREF(variable) statements, and cannot generate things like _Py_DECREF_SPECIALIZED() let alone deal with _PyList_AppendTakeRef().

• Issue: Generate the interpreter #98831

[gvanrossum]

Some thoughts about how the code would change for the register VM (to be done in a future PR):

• We need a separate way to mark an instruction as register-based in the DSL input, maybe register inst(NAME, ...)
• A register-based instruction may have at most three stack effects (inputs and outputs) in total, assigned to oparg, oparg2, and oparg3
• For those instructions, DECREF_INPUTS() expands to nothing
• The preamble would assign each input an oparg and then generate code to initialize the variable using fast_locals[opargN] instead of using PEEK(N)
• The postamble assigns the output variable the next oparg and writes it using Py_SETREF(fast_locals[opargN], variable)

[iritkatriel]

• A register-based instruction may have at most three stack effects (inputs and outputs) in total, assigned to oparg, oparg2, and oparg3

Should we make it oparg1, oparg2, oparg3? (oparg can stay for now, for "legacy" instructions that were not converted yet).

[gvanrossum]

I was hoping you'd review this PR, @iritkatriel. We can work on the 'register inst' syntax next.