Add context-aware validation functions

[sivchari]

Description

Add context.Context support to validation functions for i18n and future extensibility.

Implementation Details

Generated functions:

// New context-aware version
func ValidateUserContext(ctx context.Context, t *User) error

// Existing function delegates to context version
func ValidateUser(t *User) error {
    return ValidateUserContext(context.Background(), t)
}

Primary use case: Pass language information for i18n. Maintains backward compatibility.

Success Criteria

• Context versions generated for all validators
• Existing functions continue to work
• Context properly propagated through validation

[egor-denysenko]

Hello 👋🏻, i would like to grab this one.

[sivchari]

Sure, go ahead!

[egor-denysenko]

govalid on  context-aware-validation-func [$✘+] via 🐹 v1.25.7 took 2s
❯ make install-lefthook
go tool -modfile tools/go.mod github.com/evilmartians/lefthook install
sync hooks: ✔ (pre-commit)

govalid on  context-aware-validation-func [$✘+] via 🐹 v1.25.7
❯ git commit -S -m "feat: implement context validation function"
Can't find lefthook in PATH
Can't find lefthook in PATH

Dunno if it was ever reported but seems that lefthook doesn't work if only installed via tool directive in tool/go.mod.

Will take a look into it anyways since i don't want to skip pre-commit hooks (and never used lefthook specifically so a good opportunity for me to look into it.)

[egor-denysenko]

Here i am.

Was unsure if to also add benchmarks for Context validators.
But it would impact only two of the ones that are being compared currently in repo.
Unless it would be a good opportunity to advance #106 by adding those in there if that's envisioned.

Also not sure if every validator has to have a context cancellation check.
Maybe in the future in can be improved and client can choose which checks should have or not context checked 🤔.
But those are just ideas that i had during the implementation

[sivchari]

For the context check, I think once at the beginning should be enough. Validation logic is very fast, so checking between each field seems unnecessary. For benchmarks, we can address that in a separate issue later. No need to block this PR on it.