Move rounduint64, swapByteOrderN, test and "fix" rounduint64

[dexX7]

• rounduint64 fixed (imho)
• rounduint64 and swapByteOrderN are available via mastercore_convert.h
• both are in the namespace mastercore

Regarding the downsides of (old) rounduint64 see #178. Most significantly: it doesn't clip anymore and numbers >= 2147483648.0 are accepted. Negative numbers have a similar behavior like positive numbers, whereby this wasn't used at all until now:

rounduint64(-0.00000000) = rounduint64(0.00000000) = 0
rounduint64(-1.00000000) = rounduint64(1.00000000) = 1
rounduint64(-2.00000000) = rounduint64(2.00000000) = 2
rounduint64(-3.00000000) = rounduint64(3.00000000) = 3

rounduint64(-0.49999999) = rounduint64(0.49999999) = 0
rounduint64(-1.49999999) = rounduint64(1.49999999) = 1
rounduint64(-2.49999999) = rounduint64(2.49999999) = 2
rounduint64(-3.49999999) = rounduint64(3.49999999) = 3

rounduint64(-0.50000000) = rounduint64(0.50000000) = 1
rounduint64(-1.50000000) = rounduint64(1.50000000) = 2
rounduint64(-2.50000000) = rounduint64(2.50000000) = 3
rounduint64(-3.50000000) = rounduint64(3.50000000) = 4

rounduint64(-0.50000001) = rounduint64(0.50000001) = 1
rounduint64(-1.50000001) = rounduint64(1.50000001) = 2
rounduint64(-2.50000001) = rounduint64(2.50000001) = 3
rounduint64(-3.50000001) = rounduint64(3.50000001) = 4

[dexX7]

Added the PUSH_BACK_BYTE makros which seem very related to the swapByteOrderN functions.

As a side note: whenever you can, I suggest to use exact width types such as uint8_t, uint16_t, uint32_t, uint64_t. It's worth to look into stdint.h to see which underlying type is used and this is very relevant for 32 bit systems. Especially when it comes to the use of PUSH_BACK_BYTE.

[dexX7]

@m21: Merge, adjust or close?

[m21]

Not the best time sorry, but please don't close it. I very much like all the auto-tests. They are very useful for us going cross-platform.

[ghost]

Again, because of generous commenting and inclusion of tests, I support this being merged.

[dexX7]

I tested swapByteOrder and noticed swapByteOrder(swapByteOrder(x)) != swapByteOrder(x). This sort of implies correct ordered data might be reordered, even if this produces wrong data. I'm not sure under which circumstances this could happen (obvious case of nested functions aside), but I guess you should be aware of this (@m21).

That said, there is htobe16, htobe32 and htobe64 which might be an alternative?