Win CI: Fix and enable compiler specs

[oprypin]

No description provided.

[oprypin]

Finally, now that there are no dependencies on other PRs, I squashed all that merge-mess :>

[RX14]

I'm a bit confused as to the reason for many of these failing specs.

I'd rather not make specs pending if we don't understand why they're broken, so could you give some details?

[oprypin]

Currently all of the specs are effectively pending, I just reduce that to a dozen.

I really just don't know why these things don't work. There are no stack traces. I'm tired.
So no, I don't want to look for an explanation.

Where I did know, I already fixed them. Many of them.

Now I just want to stop the bleeding addition of more failing specs.

Additionally, I consider merging fixes to these specs before enabling specs as strictly worse; then the fix PRs have no representation in specs even if something happens to be fixed (while with this in you just flip it back from pending). Showing the specs as what they are is good.

Best (bad) example: #9387 changes specs for seemingly no reason, but actually they were failing before, if they were to run. Then it even marks a related spec as pending, as if the commit breaks that spec???

[jhass]

This looks good! Windows support is a big task and any incremental improvements are good.

[oprypin]

For the record, this PR is inconsequential for the 0.35.0 release (changes only specs), so definitely feel free to postpone it to after that

[straight-shoota]

I'd rather not make specs pending if we don't understand why they're broken

They've essentially been pending all the time because they're not included in win32_std_spec.cr. So this doesn't change anything for those specs that are now pending_win32. But it does change the specs that are no longer pending, because they work.

Thanks for your efforts @oprypin

[RX14]

Yeah, you're right, this is better, my bad!

[jhass]

🎉