GeezerVison

Problem

BindHeaders panics when a header's value slice is nil or empty:

panic: runtime error: index out of range [0] with length 0

BindHeaders passes the request header map straight to bindData, which reads
v[0] on the scalar-map paths (bind.go:245, bind.go:249) and inputValue[0]
on the tagged-struct paths (bind.go:337, bind.go:364) without checking the
length. Header["X-Empty"] = nil or []string{} therefore panics instead of
binding nothing.

Note this is not reachable from a raw incoming HTTP request — net/http never
produces an empty value slice — so it is not a remote denial of service. It is
reachable for any in-process caller that builds or mutates a Header map, and
for anything calling bindData with a map it controls.

Change

Guard both reads. An empty value slice is treated like an absent key.

[]string{""} — a present but empty value — still binds, so the check keys on
length rather than on the value being empty. TestBindHeadersEmptyStringValueStillBinds
pins that distinction.

Testing

Four tests in bind_empty_header_test.go:

• TestBindHeadersEmptyValueSlice — nil and []string{} into a tagged struct,
  as subtests, since they are distinct states reaching the same panic.
• TestBindHeadersEmptyValueSliceIntoMap — the scalar-map destination path.
• TestBindHeadersPresentValueStillBinds — the guard does not swallow a real value.
• TestBindHeadersEmptyStringValueStillBinds — []string{""} still binds.

With bind.go reverted and the tests kept, the run fails with the exact panic
above. With the change, all four pass and the full root suite stays green
(ok github.com/labstack/echo/v5), including the 86 existing binding tests.

gofmt -l is clean on both changed files; go vet is clean. echo.go and
middleware/decompress.go are flagged by gofmt on master and are untouched here.

Closes #3169