Prototype DIP11

[Martin Nowak]

I've implemented a prototype of the DIP11 draft.
http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11
https://github.com/dawgfoto/dmd/tree/DIP11

-- Restrictions --
  - It doesn't check for conflicting qualified imports (-Iacme=/path1  
-Iacme.a=/path2)
  - pragma(importpath, "<import-path>") must come lexically before the  
import
  - Untested on Windows

-- Some outcome --
  - Using '=' in [module.or.package=]<path-or-url> could be slightly  
ambiguous for '-Ihttp://acme.org?format=raw'.
  - Url syntax collides with import path lists. Currently it is allowed to  
specify -I/path1/import:/path2/import for POSIX. I've deactivated that for  
now.

    Both can be disambiguated so they are not very severe.

  - Using 'pragma(lib, "someLib")' in an imported source has no effect, as  
long as the imported module is not compiled.
  - Overall this is very limited as even the example below will only  
compile up to a linker error.

-- Testing --
  - build dmd from DIP11 branch
  - get download.py: http://codepad.org/XAvSN505
  - get test.d: http://codepad.org/BILAwzHj
  - add 'DOWNLOADTOOL= path/to/download.py' to your /etc/dmd.conf
  - compile: dmd test.d

-- Brainstorming --
We need to define a compilation model for the imported files.

One solution could be to generally change the semantics of importing to  
mean if the
imported file is a source (*.d) build an object for that module if it is a  
header (*.di) don't
build an object and leave it to the user to supply binary data.

If I somehow compile the remote sources I might want to do that including  
debug information.
This would immediately require an offline copy of the sources to work  
properly.

martin