Support 64bit MP_DIGIT on Windows under clang-cl

[R-Goc]

This commit make MP_DIGIT 64 bit when using clang-cl. It also explicitly sets compile flags for clang-cl.

[R-Goc]

This also allows for building a debug version with clang-cl. I couldn't get it to happen with msvc. As in if I did the things required for it it is no longer a debug build as it would require at least turning off real time checks (/RTC1 passed by cmake) which defeats the purpose of a debug build. Maybe I am missing something here.
Other than that on msvc there are still some warnings:

E:\lib\libtommath\mp_get_i64.c(6): warning C4146: unary minus operator applied to unsigned type, result still unsigned
[38/166] Building C object CMakeFiles\libtommath.dir\mp_get_i32.c.obj
E:\lib\libtommath\mp_get_i32.c(6): warning C4146: unary minus operator applied to unsigned type, result still unsigned
[46/166] Building C object CMakeFiles\libtommath.dir\mp_get_l.c.obj
E:\lib\libtommath\mp_get_l.c(6): warning C4146: unary minus operator applied to unsigned type, result still unsigned
[102/166] Building C object CMakeFiles\libtommath.dir\mp_set_i64.c.obj
E:\lib\libtommath\mp_set_i64.c(6): warning C4146: unary minus operator applied to unsigned type, result still unsigned
[103/166] Building C object CMakeFiles\libtommath.dir\mp_set_l.c.obj
E:\lib\libtommath\mp_set_l.c(6): warning C4146: unary minus operator applied to unsigned type, result still unsigned
[104/166] Building C object CMakeFiles\libtommath.dir\mp_set_i32.c.obj
E:\lib\libtommath\mp_set_i32.c(6): warning C4146: unary minus operator applied to unsigned type, result still unsigned
[162/166] Building C object demo\CMakeFiles\test-ltm.dir\test.c.obj
E:\lib\libtommath\demo\test.c(54): warning C4146: unary minus operator applied to unsigned type, result still unsigned
E:\lib\libtommath\demo\test.c(59): warning C4146: unary minus operator applied to unsigned type, result still unsigned

[R-Goc]

My only concern is what happens if tommath is compiled with msvc but the consumer uses clang-cl. At that point everything will break I am afraid. Is MP_WORD anywhere in the ABI of the library? If so then that could also cause issues as __int128 is not stable in the msvc ABI and afaik not even defined.

[sjaeckel]

Thanks for the PR!

Basically LGTM besides the comments.

[sjaeckel]

This change must be reverted. We decided that our header files will reside in a separate folder.

[sjaeckel]

Not sure if we want _CRT_SECURE_NO_WARNINGS defined or not. Someone else who cares about Windows as a platform has to decide on that.

[sjaeckel]

Same here.