Generate debug metadata using DIBuilder

- One DIBuilder per CU
- Pick arbitrary file for synthetic functions
  without location (e.g. ".import"), so there
  are no made up CUs.
Deduplicate init entries with different priorities by choosing the entry with the highest priority

This can happen in certain obscure cases -- see the comment for more info.
Fix gllgo, enable -g
Merge pull request #149 from axw/libgo-dibuilder

Generate debug metadata using DIBuilder
Merge pull request #161 from pcc/libgo-p1

Compute sizes and offsets ourselves with padding for embedded structures
Merge pull request #162 from pcc/libgo-p2

Deduplicate init entries with different priorities by choosing the entry...
Introduce frame.llvmvalue and port all clients which do not use govalue to it
Modify frame.slice to take llvm.Values instead of govalues
Avoid loading large structures when we are only going to use them to create an interface

This may look like an optimization, but it helps us avoid assertion failures
in the LLVM backend resulting from loads of large structures.
Modify interfaceMethod to take llvm.Values instead of govalues

Also, use the supplied interface type instead of the receiver of the
interface method. This avoids problems with embedded interfaces, and fixes
11 libgo tests.
Merge pull request #163 from pcc/libgo-llvmvalue

Introduce frame.llvmvalue and start porting clients to it
Simplify the logic for deciding whether to emit a function

This will soon exclude synthetic functions that we won't want to
exclude. Because we use linkonce_odr linkage for functions outside packages
it doesn't matter much whether we emit duplicates.
Mangle synthetic functions without a receiver using Function.String()

Such functions may be thunks whose receiver types are unavailable
through the public interface.
Add a README.patches file to make it easier to keep track of which patches we need
Do not zero memset heap-allocated variables

The allocator does this for us.
Emit more entities in a deterministic order, and do so unconditionally

The cost of doing so is small, and not enough to justify the burden of
maintaining two code paths, in my opinion. By emitting in a deterministic
order, we can check (and indeed, I have checked) the correctness of a
self-hosted build by comparing the second and third stages.
Give unexported globals internal linkage
Merge pull request #167 from pcc/libgo-glob

Give unexported globals internal linkage
Merge pull request #164 from pcc/libgo-thunk

Get us ready for an SSA change
Statically optimize initializations performed by init function

Specifically, any ostensibly dynamically-allocated memory allocated by
the init function is instead statically allocated using global variables,
provided that its initializer is dense enough (at least 1/4 of elements need
to be initialized).

Stores of constants to globals (i.e. regular globals or those synthesized
from dynamic allocations) in the init function will instead cause the global's
initializer to be modified to simulate the effect of such stores.

This saves the alias analysis a huge amount of work, in particular in
packages which make heavy use of variable initialization, such as the unicode
package. Previously the compile time for that package was measured in minutes,
now it is measured in seconds (with a debug LLVM; in release mode it will
probably be faster). Furthermore, one libgo test which previously timed
out during compilation (crypto/tls) now passes.

It could also permit further optimizations such as globalopt, but this isn't as
effective as it could be right now because the call to __go_register_gc_roots
pessimizes anything involving globals which may contain pointers. One
possible way of solving this would be to delay the insertion of this call
until after the optimizers have run, but this can wait until we're ready
for more optimizations.

As far as I can tell, this optimization is sound because the content of
the init function is carefully controlled -- it only directly performs
initialization called for by initializers of package-level variables, the
pre-initialization state of which cannot legally be observed thanks to the
initialization order rules in the spec, and it does not contain control flow
which might cause memory to be allocated multiple times.