Name the function a failed argument binding was binding for - #8630

A built-in call that binds its arguments badly said neither which function it
was binding for nor, for a method, the right numbers.

>>> [].append()
TypeError: expected at least 2 arguments, got 1     # 2 and 1 count `self`
>>> [].append(1, 2)
TypeError: expected at most 2 arguments, got 3
>>> "".split(bogus=1)
TypeError: Unexpected keyword argument bogus
>>> sorted()
TypeError: expected at least 1 arguments, got 0     # "1 arguments"
>>> float(1, 2)
TypeError: expected at most 1 arguments, got 2

self was prepended to the arguments before binding, so it was counted as
both an expected parameter and a given argument: every method reported
numbers one too high.

What this does

Callee carries what a message says about the function being called: the
name, and whether the leading argument fills the instance parameter.
PyNativeFn takes one; PyNativeFunction, PyMethodDescriptor and the four
method-descriptor call specializations in frame.rs supply it.
FuncArgs::bind_for subtracts the instance from both numbers, the way
descrobject.c reports nargs - 1 whether the caller wrote self or an
attribute lookup bound it.

Constructor::slot_new and Initializer::slot_init name the type the slot
was written for — not the subclass being constructed, and not the module
tp_name carries — and so do the 23 slots that override them.

The messages are the ones their counterparts raise:

A parameter a call may pass by name is named back when it is missing; a
positional-only one is only ever counted, so it keeps the first form. A
binding that happens where the name isn't known leaves it off, the way
_PyArg_Parser.fname is NULL.

slice() and range() counted their own arguments and raised messages of
their own (slice() must have at least one arguments.); they now raise the
one _PyArg_CheckPositional raises.

After

>>> [].append()
TypeError: append expected 1 argument, got 0
>>> [].append(1, 2)
TypeError: append expected 1 argument, got 2
>>> "".split(bogus=1)
TypeError: split() got an unexpected keyword argument 'bogus'
>>> sorted()
TypeError: sorted expected 1 argument, got 0
>>> float(1, 2)
TypeError: float expected at most 1 argument, got 2
>>> memoryview()
TypeError: memoryview() missing required argument 'object' (pos 1)

Verification

Against CPython 3.14.6 over 43 calls, 23 now produce the identical string;
of the 16 measured first, none matched before and 9 do now.

• 131 regrtest suites, 25,202 tests: SUCCESS.
• Three @unittest.expectedFailure decorators go away, all of them tests
  this fixes: test_find_etc_raise_correct_error_messages in test_bytes
  and string_tests (CPython issue 11828), and
  test_range_constructor_error_messages in test_range.
• extra_tests/snippets/vm_argument_errors.py passes under RustPython and
  under CPython 3.14.6.
• cargo fmt --check clean; clippy with CI's arguments exits 0; the first
  commit compiles on its own.

Left out

• CPython's other message families. len() takes exactly one argument (0 given) and deque() takes at most 2 arguments (3 given) come from the
  METH_O and PyArg_ParseTuple paths. RustPython has one binding path, so
  every message here is the _PyArg_CheckPositional form. The counts and the
  name are right; the wording differs for 12 of the 43 calls. Matching those
  needs the METH_* families themselves.
• takes no keyword arguments for abs(x=1), [].count(x=1),
  range(stop=5). _PyArg_NoKeywords needs to know the function accepts no
  keywords. infer_native_call_flags computes that, but its own comment
  calls it a best-effort mapping, and using it to reject a call would break
  working code wherever it is wrong.
• Counting the arguments before converting them. b"".hex(1, 2, 3) still
  says unexpected type int where CPython says hex() takes at most 2 arguments (3 given), because binding converts as it goes. Checking up
  front needs FromArgs to report whether it is variadic — PosArgs has
  arity 0..=0 today, so an early check would reject every varargs call.

Summary by CodeRabbit

• Bug Fixes

  • Improved argument validation across built-in functions, methods, and constructors.
  • Error messages now identify the called function or type and accurately report expected and provided arguments.
  • Missing required arguments now include the parameter name and position.
  • Corrected zero-argument errors for range() and slice().
  • Improved handling of unexpected keyword arguments and bound method arguments.

• Tests

  • Added coverage verifying CPython-compatible argument error messages across built-ins, methods, and types.