[cubahno]

With request validation on, an inline array query parameter checked maxLength on each item but ignored the array's maxItems, so 11 term values reached the service although the schema allows 10.
Only a named array schema checked its item count, in its own Validate(). An inline array has no Validate() of its own, and the struct holding it only checked the items, so minItems and maxItems were never enforced on an inline array, whether a query parameter, a request body property or a response property under response validation.

What changes

• A struct's Validate() checks the length of each inline array property and parameter it holds, the way a named array type checks its own. The request from the issue is now a 400, Query.Term must have at most 10 items, got 11, and doesn't reach the service. This includes an array declared in a component parameter, whose alias (type Terms = []string) has no Validate() either.
• An array that wasn't sent is nil and passes minItems; an empty one that was sent doesn't. minItems: 0 generates nothing.
• A struct whose only constraint is an item count now gets a Validate(), and one that used validator.Struct() moves to per-field checks, since no validator tag expresses an item count.
• The array's own validation tags, such as required, are checked exactly as before. Named array types, arrays referenced through $ref and arrays of inline objects, which already get a named type, generate as before. Across the 454 real-world specs that use minItems or maxItems, only Validate() methods change, in 292 of them, and the output builds.
• simple validation still runs validator.Struct() on structs, so it doesn't check item counts. The validation docs said minItems and maxItems map to min/max tags, which was never the case; they now describe the length checks.

Fixes #164