BEGIN_PUBLIC
[Stdlib] Drop the outer `GILAcquired` from `_py_c_function_wrapper`

When CPython dispatches a `PyMethodDef` entry via `METH_VARARGS` /
`METH_VARARGS | METH_KEYWORDS`, the calling thread already holds the
GIL. PyO3, pybind11, and nanobind all rely on this invariant and don't
acquire the GIL again on entry. The Mojo binding wrapper, by contrast,
wrapped the user-supplied function in an explicit `GILAcquired`
context manager, which on every call hit `PyGILState_Ensure` (state
bookkeeping in CPython) and `PyGILState_Release` on return.

Microbenchmark on the same machine as issue modular#6521 (CPython 3.12,
`taskset -c 2`), running a Python timeit loop that calls a Mojo
function via a `PythonModuleBuilder`-registered C trampoline:

  variant                                    ns / call
  ---------------------------------------    ---------
  inline pywrap + GIL                              123
  inline pywrap, no outer GIL  (this patch)        106
  ---------------------------------------    ---------
                                       delta:       17 ns

So removing the outer pair saves ~17 ns / call (~8.5% of the current
overhead). Combined with the conditional GIL handling in
`PythonObject.__del__` (companion commit), the total saving on a
single-arg trampoline is ~29 ns / call.
END_PUBLIC

Assisted-by: AI
Signed-off-by: Manuel Saelices <[email protected]>

BEGIN_PUBLIC
[Stdlib] Add `METH_FASTCALL` support to `PythonModuleBuilder`

Exposes the CPython METH_FASTCALL calling convention so extensions
written with `PythonModuleBuilder` can opt out of the
`METH_VARARGS`-style per-call tuple allocation.

What's added:

- `METH_FASTCALL = 0x80` flag (matches CPython's
  `Include/methodobject.h`).
- `PyCFunctionFast` type, the trampoline signature:
  `def(PyObjectPtr, UnsafePointer[PyObjectPtr], Py_ssize_t) -> PyObjectPtr`.
- `PyMethodDef.function_fastcall` static factory that builds a
  fastcall `PyMethodDef` with the right flag bits.
- `PythonModuleBuilder.def_py_c_fastcall_function`, a new public
  entry point parallel to `def_py_c_function` for users who want to
  ship a hand-rolled fastcall trampoline.

This is the raw-API surface — the higher-level
`def_function[user_func]` registration still defaults to
`METH_VARARGS`. Integrating fastcall into that high-level path
requires a fastcall-aware variant of the `_python_func.mojo`
dispatch chain and is left as a follow-up (this branch chains on top
of the GIL-acquire cleanup PR; the next chained PR will add the
high-level integration).

Microbench: a tight Python -> Mojo -> Python loop on a `noop(x)`
function shows the raw fastcall trampoline at ~136 ns/iter vs the
current `def_function` path at ~198 ns/iter (-62 ns, ~31%
improvement). For `add(a, b)`, ~383 ns/iter vs ~313 ns/iter
(-70 ns, ~18%). Numbers include the Mojo -> Python overhead the
bench loop pays per iter, so the win attributable purely to the
trampoline change is the delta. See the companion benchmark commit
for the full bench setup.
END_PUBLIC

Assisted-by: AI
Signed-off-by: Manuel Saelices <[email protected]>

BEGIN_PUBLIC
[Stdlib] Add Python -> Mojo FFI hot path benchmark

`mojo/stdlib/benchmarks/python/bench_python_ffi.mojo` measures the
Python -> Mojo round-trip for two trampolines side by side:

- A: the standard `PythonModuleBuilder.def_function[user_func]`
  path (METH_VARARGS, full `_py_c_function_wrapper` chain).
- B: a hand-rolled trampoline registered via
  `def_py_c_fastcall_function` (METH_FASTCALL).

Both `noop(x)` and `add(a, b)` shapes are covered, matching the
reproduction in issue modular#6521.

The bench loop runs in Mojo, so each iteration pays a Mojo -> Python
crossing in addition to the Python -> Mojo crossing we want to
measure. The absolute numbers are therefore higher than what an
external Python driver would see, but the delta between the two
variants is meaningful and attributable to the trampoline style.

Run with:

    ./bazelw test //mojo/stdlib/benchmarks:python/bench_python_ffi.mojo.bench \
      --test_output=all
END_PUBLIC

Assisted-by: AI
Signed-off-by: Manuel Saelices <[email protected]>

The rest of the python bindings code uses 'wrapper' uniformly
(_py_c_function_wrapper, _tp_dealloc_wrapper, _tp_repr_wrapper,
_py_new_function_wrapper, ...). 'Trampoline' was jargon I introduced;
swap it back to match the project's terminology.

Assisted-by: AI
Signed-off-by: Manuel Saelices <[email protected]>