msvc: Enable GC

Msvc only declares the semi-standard _bss_start and _end variables (for compatibility I guess), but they do not point to the actual bss section used. That is appended to the end of the data section by the linker so it's not possibly to look it up (or I found no way). However putting all statics in a named section and then querying the executable to figure out where the section is, and use that for the GC, seems to work just fine.
Also see #625 - a couple of tests show the behaviour is now roughly the same as gcc builds.
I've been reading about it and it's hard to find a single authorative answer. Basically ``restrict`` is a way to promise the compiler you won't be naughty with pointers but nothing except that promise stops you or other developpers from doing so anyway, now or in the future.

Also maybe I don't understand aliasing rules properly, but I am not even sure the ruls is being broken here. It is also strange that only the mingw cross-compiler complains, not standard gcc nor actual mingw on windows. I can only guess, but am assuming the reason is the latter are at least version 4.7, while the mingw cross-compiler is still stuck at 4.2. So maybe it's just a bug in that compiler? Given that, plus the links below which seem to indicate gcc makes sure that with C99 enabled using a union is the proper way to do type-punning, plus that it only happens in Travis with a 5 year old compiler and likely not in real-world situations, my opinion is that it doesn't really matter and I would prefer sticking with the union and only enable it for old versions (i.e. using ```#if defined( __MINGW32__ ) && ( __GNUC__ <= 4 ) && ( __GNUC_MINOR__ <= 2 )```), leaving the code as-is for the rest.

http://stackoverflow.com/questions/11639947/is-type-punning-through-a-union-unspecified-in-c99-and-has-it-become-specified
http://stackoverflow.com/questions/9011884/how-to-safely-perform-type-punning-in-embedded-system