Please integrate build framework into the compiler

[grauzone]

> Little self-promotion here, and in case Walter misses some of them:
> http://d.puremagic.com/issues/show_bug.cgi?id=2744
> http://d.puremagic.com/issues/show_bug.cgi?id=2745
> http://d.puremagic.com/issues/show_bug.cgi?id=2747
> http://d.puremagic.com/issues/show_bug.cgi?id=2748
> http://d.puremagic.com/issues/show_bug.cgi?id=2751

If it's about bugs, it would (probably) be easier for Walter to fix that 
code generation bug, that forces dsss/rebuild to invoke a new dmd 
process to recompile each outdated file separately.

This would bring a critical speedup for incremental compilation (from 
absolutely useless to relatively useful), and all impatient D users with 
middle sized source bases could be happy.

> In c++, a sophisticated makefile carefully build .h dependencies of .c 
> files. Thus, once .h files are updated, then .c files which are based on 
> them need to be recompile. This detection can be made by comparison of 
> old .di files and new .di files by testing their equality.

This sounds like a really nice idea, but it's also quite complex.

For example, to guarantee correctness, the D compiler _always_ had to 
read the .di file when importing a module (and not the .d file 
directly). If it doesn't do that, it could "accidentally" use 
information that isn't included in the .di file (like code when doing 
inlining). This means you had to generate the .di files first. When 
doing this, you also had to deal with circular dependencies, which will 
bring extra headaches. And of course, you need to fix all those .di 
generation bugs. It's actually a bit scary that the compiler not only 
has to be able to parse D code, but also to output D source code again. 
And .di files are not even standardized.

It's perhaps messy enough to deem it unrealistic. Still, nice idea.