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.
> The standard way to deal with compiler strict aliasing paranoia is to cast pointer to needed type via void*. Please try that before proposing unC ways like unions.

Had no idea that is the standard way, but isn't it technically still UB as it still breaks strict aliasing, it's just that the compiler doesn't see it anymore? A union on the other hand is part of the standard, sure not used often, but it's C. And correct in this case?

> please don't tell people that their compiler is old, 

It probably wasn't clear enough from my side but the I considered the part after the *and* -  *likely not in real-world situations* - more important: there is a way more recent version of the compiler available, just not of the cross-compiler. If two versions are available, the latter probably containing lots of bug fixes and other goodies, or in other words if somebody wants to get serious with uPy and mingw I'd argue they should really use the more recent version unless proven it has problems. That is rather different from your SPARC case where there's no choice whatsoever.

Anyway now there's 3 possible solutions already (restrict/void*/union), all doing the job of silencing the compiler. I have less experience than you guys so, @dpgeorge @pfalcon please pick one.