Fix an issue that the 3rd bit of scanning mode in GRIB does not affect processing

[noritada]

Hi, I found an issue that the 3rd bit of scanning mode in GRIB does not affect processing.

Example

When reading GRIB with encoded values of [0, 1, 2, 3, 4, 5] with Ni = 2, Nj = 3 and scanning mode = 0b00000000, the resulting values are [[0, 1], [2, 3], [4, 5]]. It is correct.

However, when reading the same data with Ni = 2, Nj = 3 and scanning mode = 0b00100000, the resulting values are the same, although they are expected to be [[0, 3], [1, 4], [2, 5]].

Cause

if self.has_key('jPointsAreConsecutive') and\
    self['jPointsAreConsecutive']:
    storageorder='F'
else:
    storageorder='C'
datarr = np.zeros(size, np.double, order=storageorder)
err = grib_get_double_array(self._gh, name, <double *>datarr.data, &size)

In the code above, an array with the intended order is created and assigned to datarr. However, as far as I checked using np.isfortran(), datarr always becomes C-ordered (np.isfortran(datarr) always returns False) after the data read by grib_get_long_array() or grib_get_double_array() is assigned to datarr.data.

Additional information

• Because some of the changes in this fix depend on my PR #212, the branch is derived from that branch and the diff of this PR will include the contents of that PR. I will rebase when that PR is merged. Sorry.
• As far as I know, I didn't find any data using this 3rd flag, so it probably doesn't affect users much. Just my personal data happened to use this flag.
• I'm not sure if it was working correctly originally and the changes in NumPy caused this issue to occur, or if it wasn't working properly to begin with. At least I confirmed it with NumPy 1.23.0, which is available in my environment.

Many thanks.

[jswhit]

@noritada I believe this was a bug, thanks for fixing it. I will merge as soon as you rebase.

[noritada]

@jswhit Thank you for merging the previous PR. I have rebased and re-pushed the branch for this PR.