bpo-36511: fix -u parameters

[paulmon]

Based on the buildbot log output
-unetwork,decimal,subprocess,urlfetch,tzdata
is being transformed to
-unetwork decimal subprocess urlfetch tzdata

Notice the missing commas. I don't know if this is causing the current failures but it seems incorrect.
Also, I'm not sure why this didn't go in the build master config instead of the .bat file. Maybe it should be moved if this fixes something.

@zooba @zware

https://bugs.python.org/issue36511

[miss-islington]

Thanks @paulmon for the PR, and @zooba for merging it 🌮🎉.. I'm working now to backport this PR to: 3.8.
🐍🍒⛏🤖

[bedevere-bot]

GH-14290 is a backport of this pull request to the 3.8 branch.

[paulmon]

@zooba

It looks like fixing test.bat fixed the test_socket failures. It passed on 3 buildbot builds in a row (2 debug, 1 retail, 2nd retail build is still running). I'm keeping an eye on this one to make sure it's not still timing out sometimes.

There are still failures in test_time and test_strptime

The failures in test_time have the same root cause inside the CRT as the other time bug I worked around (_tznames[] returns empty strings). timemodule.c (line 503) strftime(zone, sizeof(zone), "%Z", &buf); returns "" in zone

All of the tests in test_strptime have a ‘%Z’ in them. Which is the format string which when passed to strftime in timemodule.c that returns an empty string (should print the timezone).

Do you think I should try to workaround all of the %Z failures? Fixing all of the place strftime or strptime is used looks more complicated than fixing time.tznames was.