Properly handle NULs when normalizing SFP fields

Some generic 1.25gbps DAC cables were seen to have a NUL *after* the
space padding in the model field. This caused the normalization to miss
the space padding in the string. The vendor field did not have the
issue.

Note that this seems to be against spec per SFF-8472, which mentions
only space padding or *all* NUL, not a combination of both. In the case
of all NUL, we'll waste a few cycles with no-op writes.

sfp.c

@@ -95,7 +95,7 @@ bool sfp_read_field(__xdata char *dst, uint8_t sfp, uint8_t start, uint8_t lengt
 		dst[i] = c;
 	}
 
-	while (length > 0 && dst[--length] == ' ')
+	while (length-- > 0 && (dst[length] == ' ' || dst[length] == NUL))
 		dst[length] = NUL;
 
 	return true;