Add GRIB2 workaround helper for int32->uint32.

Partner in crime to #1480.
My understanding is that in sign and magnitude `0x80000000` is the value with the sign bit set i.e. `0b10000000000000000000000000000000`, which corresponds to -0. As we set lower bits the result is getting increasingly negative. In two's complement this number is the most negative number we can represent (i.e. -2147483648) and as we set other bits we get less negative. In python 0x8000000 as a literal is 2147483648. If we have a signed int32 coming in (between -2147483648 and 2147483647) and for negative numbers we subtract from 2147483648 we shift from [-2147483647 to 2147483647] to [2 * 2147483648 to 2147483649 and 0 to 2147483647]. In hex this looks like `[0x100000000, 0xFFFFFFFF, 0xFFFFFFFE, ..., 0x80000001 to 0x00000000, 0x00000001, ..., 0x7FFFFFFF]`. So if we assume we can ignore -2147483648 (ie. limit range to 32 bit sign and mag) we get out [0xFFFFFFFF, ..., 0x80000001, 0x00000000, ..., 0x7FFFFFFF], which is [-2147483647, ..., -1, +0, ..., 2147483647] when interpreted as sign and mag. :+1: