Resolve MSVC Warnings, main branch (2021.09.13.)

[krasznaa]

As @stephenswat could see it ahead of time, #100 set some things in motion... (I'll be setting up a CI for Windows next. 😛)

Here I enabled roughly the same level of warnings for MSVC that we use with GCC and Clang as well. I did not use /Wall as the warning level, as that seemed a bit ridiculous. Even the Microsoft documentation recommends against using that. (With that enabled, even the test code from https://github.com/acts-project/vecmem/blob/main/core/CMakeLists.txt#L79-L84 would not compile. So at that point I have up on that warning level.)

Then I set out to fix all of the warnings that MSVC would print. Which are mostly integer type issues. MSVC really doesn't like it when you implicitly convert between different integer types... Since, as is discussed in #96, we use std::size_t as the size type in some places, and unsigned int in others, I had to make the code very explicit about type conversions in a good number of places. I'm not super happy about this either, but at the same time it did make the code a lot more explicit about what it expects the compiler to do...

I was pondering about https://github.com/acts-project/vecmem/blob/main/tests/core/test_core_contiguous_memory_resource.cpp for a bit. Since this test fails with MSVC in Debug builds. For multiple reasons actually. First off, in a Debug build it's a runtime error to de-reference std::vector<T>::end(). But even if I don't do that in the code, the test still fails. As in Debug mode MSVC pads all STL containers by some amount. To make it easier to detect out-of-range accesses in the code.

I was wondering about replacing std::vector with simple allocation/de-allocation calls in the tests, but in the end rather decided to just disable it for Debug builds with MSVC. But I'm not completely happy with this setup either...

I still maintain that listening to warnings from yet another compiler is a good thing! So I still very much want to go forward with this, even with all the necessary changes. (Note that the library code itself had to be changed very little. It was mostly the tests that needed adjustments.)

[stephenswat]

I think this is great, the mixed integers are a real potential problem, and it's good to make these conversions explicit. In the long time as you say you would want to change the underlying types so they become compatible, but for now it's fine.

Regarding the contiguous tests, yes they are indeed fragile, and perhaps the tests are fundamentally badly designed. We should revisit them sometimes. I like the idea of moving to "raw" allocations, rather than using the resource through a vector.