lseek: Correct order of offset arguments

There was a runtime error in systems without large file support. Call
fseek(fd, 4096, SEEK_SET) has been failing with EINVAL, though it was
succeeding for offset = 4092. This has been happening because llseek system
call accepts 64-bit value as an offset argument and lseek function has been
ordering 32-bits words in it according to the endianness (most significant
part is 0, since lseek itself accepts only one 32-bit offset. However this
ordering to match endianness is not required, llseek will contruct 64-bit
offset value properly, using "offset_high" argument as a most significant
word, and "offset_low" as a least significant. As a result of this double
swap it was happening that call to fseek with offset 4096 (0x1000) was
causing a system call llseek with offset 0x1000 0000 0000. I'm not entirely
sure why then offset = 4092 hasn't been failing.

This patch removes malicious swap of words when calling llseek.

Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>