Interpreter: fix architecture-dependent rounding order in non-IEEE mode

PPC and x86 behave differently in non-IEEE mode (NI=1/FTZ):

For single-precision floating point operations with denormal inputs (and frsp with a denormal output), PPC first flushes the input to zero, then applies the current rounding mode while x86 does it the other way around. At least this would explain what happens.

Ignoring the sign bit, the only range in which this affects the output is `[0x380ffffff0000000, 0x380fffffffffffff]`. On PPC, a number in this range results in `0` while on x86 it results in `0x3810000000000000`. An example of this bug can be seen when running the [frsp hwtest](https://github.com/dolphin-emu/hwtests/blob/master/cputest/frsp.cpp).

All credit goes to @FioraAeterna for finding the cause of this bug.

This PR fixes both an extended frsp hwtest as well as a simple fadds test I haven't pushed yet.

TODO:
- Find out if this madness is actually true or just a hallucination caused by sleep deprivation.
- Investigate what ARM does.
- Fix the JITs.