feat(scripting/lua): add getnparams to client debug sandbox

[Peter-Greek]

Goal of this PR

Add additional functionality to the new client sandboxed lua debug lib as much of its functionality was removed.

How is this PR achieving the goal

Added the debug.getnparams() function to be used on the client. This is a bypass for the unsafe debug.getlocal(), so devs can still get the parameter names of a function passed as the argument to the new function.

New lua docs for the debug function

---
--- Returns a table with the function parameter names from 1 to `nparams`, or **nil** if `nparms` 
--- is not available. Variable arguments are ignored but will still return parameters before it.
--- `self` is included as the first parameter if the function is a method.
---@param f function
---@return table
function debug.getnparams(f) end

This PR applies to the following area(s)

ScRT: Lua

Successfully tested on

Unable to build fivem on my laptop but did test it on Windows 10, using a simple C++ script and lua script and the code compiled and ran as expected. Used the functions in the file LuaDebug.cpp as reference to ensure consistency.

Game builds:

Platforms:

Checklist

• Code compiles and has been tested successfully.
• Code explains itself well and/or is documented.
• My commit message explains what the changes do and what they are for.
• No extra compilation warnings are added by these changes.

Fixes issues

Addresses #3010

[iridium-cfx]

So, I am tempted to allow the name-only path of getlocal, but I would still like to understand what people's use-cases for it are. Though if we do add it back, it will be easier to just remove the unwanted parts of the original getlocal, rather than adding a new function.

[thelindat]

https://forum.cfx.re/t/why-disable-the-debug-lib-without-warning/5291361

[Peter-Greek]

So, I am tempted to allow the name-only path of getlocal, but I would still like to understand what people's use-cases for it are. Though if we do add it back, it will be easier to just remove the unwanted parts of the original getlocal, rather than adding a new function.

I mentioned a few times some use cases but quick synopsis is being able to get the names of function parameters, this can be used in things like function overloading (calling functions with the same name or functionality based on the parameters it accepts). Atm without the use of getlocal it is impossible to do this.