Start using the ddmd frontend to more narrowly scope imports

[joakim-noah]

I just modified the ddmd frontend to dump all imported symbols, based on Daniel's newmagic ddmd branch from a couple weeks back. I was able to make these small cleanups by running this modified ddmd on std.stdio and looking for places to tighten up the imports, doing more soon.

I'm posting this PR early so that it can be looked over as I go, and run through the auto-tester.

[joakim-noah]

I think I'm done with std.stdio, more narrowly scoping as many imports as I could, all from druntime. Given issue 314, ie module-scope selective imports are incorrectly made public, I did not use any selective imports at module scope, even reversing the recent selective import of Flag so that it isn't made public. I'd like to have reversed the selective import of HANDLE on Windows also, but that made it into official releases, so I figured better not break code that relies on that bug, at least until issue 314 is fixed in dmd.

Since I can't make them selective yet, I documented the symbols imported by the remaining module-scope imports in comments. I was able to remove some static imports after more narrowly scoping core.sys.posix.stdio, since functions like fileno, fopen, and fdopen are confusingly declared twice, there and in core.stdc.stdio.

This PR is now ready for review. If these kinds of changes are found worthwhile, I may submit more PRs for other modules.

[joakim-noah]

Updated this pull to localize symbols where possible from module-scope imports std.range.primitives and std.traits, so that the remaining commented-out module-scope symbols can be made into a selective import once issue 314 is fixed.

Should be finally done now.

[DmitryOlshansky]

Looks nice but I worried if some symbols are only required on some platforms and not the other.
std.stdio is not that well covered by tests to be certain...

[joakim-noah]

The auto-tester did catch some of these for me on FreeBSD or Windows that ddmd didn't, since I was only running the ddmd frontend for linux. If the test coverage isn't complete, it's possible that some other missed dependency slipped through.

But maybe that's a reason to do it anyway, to help us find where the test coverage needs to be improved?

[joakim-noah]

Oh, also, many phobos modules were recently updated by @9il (#2727 for this module) to more narrowly scope other phobos imports, so if they're going to break because of bad test coverage, that's already been done.

[ghost]

Why was a selective import replaced with a regular import? Seems like it's doing the opposite of what we need.

[joakim-noah]

I laid out the reason in my second comment above. Issue 314 is that selective imports at module scope are currently always public, ie those symbols are leaked into any module that imports this module. Since this selective import was added between major releases, I thought it best to reverse it, until issue 314 is fixed, so that it won't leak in the next release.

[ghost]

Ah right, forgot about that. Cool. :)

[ghost]

std.stdio is not that well covered by tests to be certain...

Yeah I think we need to have some kind of version (TestStdio) stdout = <some_output_buffer> or something to that effect, and then write a proper test-suite for std.stdio. Just relying on intuition that it works is not good.

But that's another step for later. This mostly LGTM. Will have another deeper look later and merge.

[ghost]

Auto-merge toggled on