gh-144650: support Vectorcall for _decimal.Decimal's

[skirpichev]

This shows almost no effect on "official" pyperformance benchmarks (see python/pyperformance#473):

Benchmarks with tag 'decimal':
==============================

decimal_pi: Mean +- std dev: [ref] 1.97 sec +- 0.01 sec -> [patch] 1.95 sec +- 0.02 sec: 1.01x faster

Benchmark hidden because not significant (1): decimal_factorial

Geometric mean: 1.01x faster

But on micro-benchmarks:

Benchmark	ref	patch
Decimal(0)	620 ns	537 ns: 1.15x faster
Decimal(123)	621 ns	540 ns: 1.15x faster
Decimal('123')	788 ns	677 ns: 1.16x faster
Geometric mean	(ref)	1.16x faster

(Default ./configure options, gcc 14.2)

Details

# bench.py
import pyperf
from decimal import Decimal

runner = pyperf.Runner()
for x in [0, 123, '123']:
    h = f"Decimal({x!r})"
    runner.bench_func(h, Decimal, x)

• Issue: Speed regression in the decimal module due to using heap types #144650

[cmaloney]

#157968 may help with the build failures (changes how the assert works which should make it better across module boundaries)

[skirpichev]

Thanks. The Decimal is only possible candidate being a heap type in the stdlib. That was worked before in skirpichev#18

[cmaloney]

👍 hopefully will get more of these landed soon :). str and list still need some special work for stable performance over the change which I'm still root causing (likely compiler inlining vs. existing hand inlining). If there are ways I can help enable / particular edge cases you find let me know. Otherwise planning to make PRs as I have time + performance results for existing cases across the codebase (int, float, str, list, bytes, bytearray, bool, filter, set, frozenset are on my radar).

[skirpichev]

CC @vstinner, does it make sense for you?