Fix for aligned move of unaligned data in 32 bit platforms.

Reproducers: tests\new-delete-5.ispc and tests\new-delete-6.ispc (with --arch=x86)

ISPC assumes 16 byte alignment of vectors, which is good for performance, but is not completely correct. 32 bit Linux and Windows malloc guarantees only 8 byte alignment (64 bit versions are ok).

The fix introduces different sets of memory allocation routines for 32 and 64 bit runtimes (with _32rt and _64rt suffixes). 32 bit version uses aligned memory allocation (posix_memalign() on Linux and _aligned_malloc on Windows). 64 bit version uses old malloc implememnation.

ISPC has single implementation of __new_* and __delete_* intrinsics for 32 and 64 bit platforms, which is strictly speaking incorrect, as signatures of malloc on 32 and 64 bit are different (as size_t has different definition). So there's single definition in *.ll files, which compiled as 32 or 64 bit code at compile time (depending on --arch switch). But it does work, as passing 64 bit value instead of expected 32 bit value as a *single* parameter works ok on 32 bit platform. This also causes unnecessary converts 32->64->32 bits, as __new_uniform takes 64 bit integer as size arguments (on 32 bit platform it should be i32).

With this solution we still have single .ll library, but we should change it in the future to be separate libraries for memory routines on 32 and 64 bits.

Possible issues with this solution: if unaligned pointers come from outside, we still may have problems, this needs to be studied further to understand how to ensure that we use aligned instructions only when appropriate.

Advantage of this solution is that it may be used for 32 byte alignment of AVX and MIC vectors.

Changes were tested on Windows and Linux on 32 and 64 bits. They fix two fails on 32 bits on both platforms.