Do not zero memset heap-allocated variables

The allocator does this for us.
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.
Merge pull request #165 from pcc/libgo-init

Statically optimize initializations performed by init function