fix: relax it.WithoutNth type constraint from comparable to any

[deepakganesh78]

Fixes #959

Problem

it.WithoutNth uses T comparable type constraint, but lo.WithoutNth correctly uses T any. Since WithoutNth only operates on indices (nths ...int) and never compares T values, the comparable constraint is unnecessarily restrictive. This prevents using it.WithoutNth with non-comparable types such as slices, maps, or funcs.

Reproduction

go seq := slices.Values([][]int{{1, 2}, {3, 4}, {5, 6}}) result := slices.Collect(it.WithoutNth(seq, 1)) // compile error: []int does not satisfy comparable

Root Cause

The T comparable constraint on it.WithoutNth was copied from it.Without (which genuinely needs it to compare values). But WithoutNth calls RejectI (T any) and lo.Keyify on nths ([]int), neither of which requires T to be comparable.

Fix

• Changed it.WithoutNth type parameter from T comparable to T any
• Fixed doc signatures in docs/data/core-withoutnth.md (lo.WithoutNth was already T any in code but T comparable in docs)
• Fixed doc signature in docs/data/it-withoutnth.md

Compatibility

This is a non-breaking change. Loosening a type constraint from comparable to any is backward compatible — all existing code continues to compile, and new code with non-comparable types now also works.

Validation

ok github.com/samber/lo 8.391s ok github.com/samber/lo/it 0.536s ok github.com/samber/lo/mutable 0.396s ok github.com/samber/lo/parallel 0.386s

go build ./..., go vet ./..., and gofmt all clean. Added regression test TestWithoutNthNonComparable that verifies non-comparable types ([][]int) work correctly.