Document best practices in preparing arguments for cuLaunchKernel

[leofang]

@gigony complained the following example is unclear compared to CuPy's RawKernel, and I agree.

cuda-python/docs_src/source/overview.md

Lines 208 to 223 in e1e3325

	Like `cuMemcpyHtoDAsync`, `cuLaunchKernel` expects `void**` in the argument list. In
	the earlier code example, it creates `void**` by grabbing the `void*` value of each
	individual argument and placing them into its own contiguous memory.
	```{code-cell} python
	# The following code example is not intuitive
	# Subject to change in a future release
	dX = np.array([int(dXclass)], dtype=np.uint64)
	dY = np.array([int(dYclass)], dtype=np.uint64)
	dOut = np.array([int(dOutclass)], dtype=np.uint64)
	args = [a, dX, dY, dOut, n]
	args = np.array([arg.ctypes.data for arg in args], dtype=np.uint64)
	```
	Now the kernel can be launched:

Specifically, how to pass typed pointers and scalars is really unclear.

This also raises the question: It seems NumPy has to be a run-time dependency of cuda-python (which is completely fine, since it is impossible that users have GPU projects installed to an environment where NumPy does not exist, we just need to ensure this intent is expressed as a package dependency).

For comparison, here's cupy.RawKernel's documentation
https://docs.cupy.dev/en/stable/user_guide/kernel.html#kernel-arguments

[vzhurba01]

https://github.com/NVIDIA/cuda-python/blob/main/cuda_bindings/tests/test_kernelParams.py

To add on, ctypes is another alternative for constructing kernel params. Both the ctypes and numpy approaches are tested in test_kernelParams.