add a new argument on the register command feature

[OualiS]

Description

This PR introduces per-argument validation support in ESX.RegisterCommand.
It allows developers to define an isValid function (and optional error message) directly inside each argument definition, enabling more granular control and safer command usage.

As an example, the /giveitem command now enforces that the count argument must be a positive number.

---

Motivation

Previously, command validation in ESX was limited:

• Only basic type casting (number, string, player, etc.) was enforced.
• Additional constraints (like positive-only numbers) had to be handled manually in the callback.

This led to duplicated logic across commands and inconsistent error handling.

By adding isValid support, validation becomes declarative, reusable, and consistent across the framework.

---

Implementation Details

• Updated the argument parsing logic inside ESX.RegisterCommand:

  • After type parsing, the final parsed value (newArgs[v.name]) is passed into v.isValid.
  • pcall is used to protect against errors inside the validator function.
  • A custom error message can be provided via v.error, otherwise a generic localized error is used.
  • Validation runs only if no prior error was detected for the argument.

• Backwards compatibility is maintained:

  • Existing commands without isValid continue to work.

---

Usage Example

ESX.RegisterCommand(
    "giveitem",
    "admin",
    function(xPlayer, args)
        args.playerId.addInventoryItem(args.item, args.count)
    end,
    true,
    {
        help = "Give an item to a player",
        validate = true,
        arguments = {
            { name = "playerId", type = "player" },
            { name = "item", type = "item" },
            {
                name = "count",
                type = "number",
                isValid = function(n) return type(n) == "number" and n > 0 end,
                err = TranslateCap("commanderror_argumentmismatch_positive_number", "count")
            },
        },
    }
)

---

PR Checklist

• My commit messages and PR title follow the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) standard.
• My changes have been tested locally and function as expected.
• My PR does not introduce any breaking changes.
• I have provided a clear explanation of what my PR does, including the reasoning behind the changes and relevant context.

[Kenshiin13]

LGTM, thanks!

[Kenshiin13]

esx-framework/esx-legacy-documentation@cc2c8a3