fix: AVP decoding panic on dictionary/wire type mismatch

[masu-mi]

Fix 2 bugs caused panics when a received Diameter message contained AVPs whose wire payload differed from the dictionary definition.

Add regression tests.

bugs

• diam/avp.go: DecodeFromBytes()
  • when the decoded type's Len() does not match the wire payload length, fall back to datatype. Unknown so that AVP.Len() returns the correct wire size and the parent parse loop advances by the right offset.
• diam/group.go: DecodeGroupedFromBytes()
  • break out of the sub-AVP loop when a fatal decode error leaves avp.Data == nil, preventing a nil-interface panic in avp.Len().

[fiorix]

Thanks, this is the right direction and covers the DecodeGrouped nil-Data panic class more completely than #235. Preserving malformed known AVPs as datatype.Unknown keeps the parent parse loop aligned, and the grouped fatal-error guard avoids the avp.Len() nil dereference.

I verified locally on bb5745d:

• go test ./diam
• go test ./...
• go test -race ./diam
• go test -race ./...
• go vet ./diam/...

All passed. go vet ./... still reports the existing t.Fatalf-from-goroutine issue in examples/s6a_proxy/service/test, which is unrelated to this PR and already covered by #250.

The broader M-bit / DIAMETER_AVP_UNSUPPORTED / Failed-AVP behavior discussed on #235 should stay as a separate protocol-handling follow-up. No blocking comments from my pass.

[masu-mi]

Thank you for thoughtful review.