fix issues #10442 and #10786: no or incomplete RTInfo

build TypeInfo in semantic, not during code-gen. This fixes RTInfo generation use by the precise GC implementation.

http://d.puremagic.com/issues/show_bug.cgi?id=10786

happens if the TypeInfo is referred to during the semantic3 pass, but is added to a module that has already completed the semantic3 step. This is fixable using the new deferred-semantic3 list. But the fixed version often triggers the next bug:

http://d.puremagic.com/issues/show_bug.cgi?id=10442

The problem is that the TypeInfo records are generated only from the glue or backend layer (e2ir.c or toobj.c) by calling Type::getTypeInfo(NULL), which outputs the TypeInfo without further analysis to the object file.
This ignores the RTInfo definition and just writes 0/1 depending on whether there are pointer fields in the struct/class or not.

Assuming that it is a bug to call Type::getTypeInfo(NULL) after semantic3 is finished, this patch forces the creation of the TypeInfo records during semantic for those expressions that later need them in the glue layer. A
problem with that approach is that it adds the TypeInfo of imported code into the object file (as COMDAT) if it is used in CTFE or type inference (similar to template functions). This makes http://d.puremagic.com/issues/show_bug.cgi?id=10831 show up more often.

Another problem is that the type of expressions is often changed later by implicite/explicite
conversions. This makes it hard to actually find those changes and generate TypeInfo
records for the new types aswell, leaving the original records unused.

I've made calls to getTypeInfo(NULL) that would trigger the creation of new TypeInfo records an ICE, but we might want to change the ICE to a warning to avoid breaking code that does not rely on proper TypeInfo.