Fix trr magic number reading
The trr header-reading routine returned an "OK" value if the magic
number was wrong, which might lead to chaotic results everywhere,
because checking of return values tends not to happen (even when
they're right). Other GROMACS magic-number reading routines tend to
give a fatal error if the the number is wrong, e.g. by reading a file
written in wrong endianness. (This should never be a thing for XDR
files, which are defined to be big endian, but such code has existed.)
This change adds/restores that behaviour to trr reading, along
with separating the behaviour of failing to read a magic integer
from reading one that doesn't match.
Fixes #1926
Change-Id: I3cdd8ae9172e3b95fc232d8fa31a442d239233db