fix(bind): restore []string values for map[string]interface{} duplicates

[leno23]

Summary

• Fix regression when binding multipart form data with duplicate field names to map[string]interface{}
• Store a single value as string and multiple values as []string

Problem

Since v4.13.0, binding duplicate multipart fields like two ima_slice values to map[string]interface{} only kept the first value. Applications expecting a slice silently broke.

This regressed after #2656, which intended to preserve pre-v4.12.0 single-string behavior but always bound v[0].

Fix

For map[string]interface{} / map[string]any:

• one value → string
• multiple values → []string

Test plan

• Updated TestDefaultBinder_bindDataToMap
• Added TestBindMultipartFormToMapInterface
• go test ./... -run 'TestDefaultBinder_bindDataToMap|TestBindMultipartFormToMapInterface'

Fixes #2731

[vishr]

Heads-up for whoever reviews this: binding map[string]interface{} to the full []string (rather than the first value) is the behavior that was intentionally reverted in #2656 (which undid #2554) after it broke users who relied on the first-value semantics. The current // To maintain backward compatibility, we always bind to the first string value comment documents that decision.

This PR re-introduces the slice behavior for the duplicate-key case, so it would re-break the same users #2656 was protecting. That may well be the right call for v5 (a major version is the place to change it) — just flagging that it's a deliberate backward-compat reversal, not a pure bugfix, so the decision is made consciously and noted in the v5 migration guide if accepted.