Fix Fetch win32 heap corruption; align time_t sizes with Unix behavior (64bit time_t on x64, 32bit time_t on x86)

_USE_32BIT_TIME_T is needed on x86.
Consider rrd_client.c:320 when time_t is 64 bit, but longs are 32:
```
if (strncmp (value, "N:", 2) == 0)
    snprintf (temp, sizeof (temp), "%lu:%s",
        (unsigned long) time (NULL), value + 2);
```
or
```
static int calculate_elapsed_steps(
    rrd_t *rrd,
    unsigned long current_time,
```

Additionally, it seems that different binaries/libraries have different heaps; calling the rrd_fetch function in librrd-4 allocates a block of data from the heap of that library, but when rrdtool is calling its free(void*), it is returned to the heap of rrdtool.exe which causes a heap validation error such as:
```
===========================================================
VERIFIER STOP 00000006: pid 0x28CC: corrupted heap pointer or using wrong heap 

	08031000 : Heap used in the call
	07F93FE8 : Heap block
	00000014 : Block size
	07F01000 : Heap owning the block
===========================================================
This verifier stop is not continuable. Process will be terminated 
when you use the `go' debugger command.
===========================================================

(28cc.1e3c): Break instruction exception - code 80000003 (first chance)
eax=00000000 ebx=00000000 ecx=0f91cae0 edx=00000000 esi=08030000 edi=08030000
eip=0f8eb966 esp=00e4f6e0 ebp=00e4f6fc iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
verifier!VerifierStopMessage+0x206:
0f8eb966 cc              int     3
0:000> kb
ChildEBP RetAddr  Args to Child              
00e4f6fc 0f8e9955 00000006 0f8e141c 08031000 verifier!VerifierStopMessage+0x206
00e4f760 0f8e9c21 08031000 00000000 07f93fe8 verifier!AVrfpDphReportCorruptedBlock+0x185
00e4f7c8 0f8e6c9a 08031000 07f029f4 00000000 verifier!AVrfpDphCheckPageHeapBlock+0x161
00e4f7f4 0f8e6e40 08031000 07f93fe8 00e4f868 verifier!AVrfpDphFindBusyMemory+0xda
00e4f810 0f8e8c00 08031000 07f93fe8 770555c5 verifier!AVrfpDphFindBusyMemoryAndRemoveFromBusyList+0x20
00e4f82c 770dceee 08030000 01001002 07f93fe8 verifier!AVrfDebugPageHeapFree+0x90
00e4f878 77088973 08030000 01001002 07f93fe8 ntdll!RtlDebugFreeHeap+0x2f
00e4f8fc 77052664 00000000 07f93fe8 07f9dfd8 ntdll!RtlpFreeHeap+0x74
00e4f920 00f22cca 08030000 00000000 07f93fe8 ntdll!RtlFreeHeap+0x206
00e4f934 00f21e1f 07f93fe8 00f3c74a 00000006 rrdtool!free+0x1c [f:\dd\vctools\crt_bld\self_x86\crt\src\free.c @ 51]
00e4f9b0 00f22593 00000006 0803df48 00f40040 rrdtool!HandleInputLine+0x65f [e:\work\utilities\hack day\rrdtool-1.x-master\src\rrd_tool.c @ 700]
00e4fa14 76d7850d 7eede000 00e4fa64 7705bf39 rrdtool!main+0x2c3 [e:\work\utilities\hack day\rrdtool-1.x-master\src\rrd_tool.c @ 520]
00e4fa20 7705bf39 7eede000 573ca097 00000000 KERNEL32!BaseThreadInitThunk+0xe
00e4fa64 7705bf0c 00f24862 7eede000 ffffffff ntdll!__RtlUserThreadStart+0x72
00e4fa7c 00000000 00f24862 7eede000 00000000 ntdll!_RtlUserThreadStart+0x1b
```

Calling `rrd_freemem(void*)`resolves that.