TST: test_nodata respect endianness

[tylerjereddy]

Fixes #15931

• the nodata.arff file read by this test contains
  no data whatsoever that could possibly indicate
  the desired endianness of the empty data fields,
  so adjust the test to expect the native endianness,
  and pass on the big endian gcc compile farm machine
  gcc203

• even if there were actual floating point values
  in the fields, I still don't see how we'd retrive
  the desired endianness from those--it seems like
  we'd still end up with the native endianness of
  the machine reading the file, and this is indeed
  what happens for me when I test on gcc203 with
  our loadarff docstring example:

Python 3.9.12 (main, Mar 24 2022, 13:02:21)
[GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from scipy.io import arff
>>> from io import StringIO
>>> content = """
... @relation foo
... @attribute width  numeric
... @attribute height numeric
... @attribute color  {red,green,blue,yellow,black}
... @data
... 5.0,3.25,blue
... 4.5,3.75,green
... 3.0,4.00,red
... """
>>> f = StringIO(content)
>>> data, meta = arff.loadarff(f)
>>> data
array([(5. , 3.25, b'blue'), (4.5, 3.75, b'green'), (3. , 4.  ,
b'red')],
      dtype=[('width', '>f8'), ('height', '>f8'), ('color', 'S6')])
>>>

• the only other solution I could think of is if this file
  format specification stipulated that retrieved data were
  to be encoded as little endian--I didn't find evidence of
  that based on the descriptions I could find online for
  this ASCII file format

[rgommers]

This looks right to me, thanks for the detailed description @tylerjereddy

[rgommers]

LGTM now, thanks @tylerjereddy