Fix/optimize ms ticks (C_GetTickCount)

There was two issues with the current implementation of C_GetTickCount (returning ms ticks to KOD):

1) MINOR: It was directly calling the Windows API (GetTickCount() in kernel32.dll), so it broke any Linux build. This was changed by calling the blakserv integrated function GetMilliCount() from time.c, which already has a Linux & Windows implementtation and which also uses QueryPerformanceCounter() on Windows with a precision of 1ms (or better, but we keep it ms, rather than the ~16ms from GetTickCount)

2) MAJOR: It was not correctly handling "roll-overs" of maximum blakserv positive integer values, and was returning negative numbers to blakserv A LOT.
Specifically: Blakserv integers have 28 bits only and the high-bit is the sign - so anything bigger than 0x07FFFFFF (134217727) will be treated as a negative number.

However the old implementation just returned the value without any modifications, meaning it returned all low 28-bits untouched from the low 32 bits (int cast) of the 64 bits.
This means after the positive values were exceeded (tick 0 to 134217727 ms) after ~37 hours, this function returned negative values for about 1118 hours (tick 134217728 to 4160749567 ms). This means while the bits 27-31 iterate, the value stays negative, before finally the 32-bit would have rolled over.
Would wrapping this in abs() help prevent passing negatie numbers?