Fix genCmain code to remove ambiguity of &main expression

[9rnsr]

It was introduced by pull #2476, but the expression &main which is implicitly
inserted would conflict with two extern(C) and (D) "main" functions in
user module.

Instead, separate the entry-point code in the hidden module __entrypoint.d

[MartinNowak]

This needs to be obj_start(modules[0]->srcfile->toChars());.

[9rnsr]

Thanks. Will fix.

[MartinNowak]

It was introduced by pull #2476, but the expression &main which is implicitly
inserted would conflict with two extern(C) and (D) "main" functions in
user module.

If there is a extern(C) main in the user module adding another extern(C) main makes two entry points.
This needs a little more thought, for example we could disallow extern(C) + extern(D) main. Any ideas?

[WalterBright]

I don't understand the problem that this pull addresses?

[9rnsr]

By the #2476 change, extern(C) main is implicitly inserted in the place where extern(D) main exists.
After the insertion, the code would be made as follows.

// in user module
void main() { ... }  // user-defined extern(D) main

extern(C) {
int _d_run_main(int argc, char **argv, void* mainFunc);
int main(int argc, char **argv) { return _d_run_main(argc, argv, &main); }   // X
version (Solaris) int _main(int argc, char** argv) { return main(argc, argv); }
}

At the line X, the expression &main has essential ambiguity between the address of D main and C main. The problem will appear when #2130 is merged. (This is not just only an internal issue. D programmer can take the D main function address and test it like this. )

In other words, current entrypoint insertion way is relying on the current incorrect overload resolution behavior. After fixing the bug by #2130, it will cause a problem.

This PR fixes the currently hidden issue.

[9rnsr]

Updated to fix the bugs that pointed out by @dawgfoto.

Now, #2130 is based on this PR, and its auto-tester result also shows green (link).

[MartinNowak]

This crashes when you compile a library, because obj_write_deferred accesses Module::ident which is NULL.
This would work.

    Identifier *id = Lexer::idPool("__entrypoint");
    Module *m = new Module("__entrypoint.d", id, 0, 0);

[9rnsr]

Thanks very much! Fixed.

[9rnsr]

Thanks!