Make the PEi386 linker able to handle symbols in .bss sections
(almost) correctly:

* "Anonymous" bss sections (where something like
     static int a[10]
  lives) are given a calloc'd block of memory to live in.

* Publically visible bss-resident symbols, such as
    int a[10]
  are each given their own calloc'd block.  The normal
  way of things is for identically-named symbols in different
  modules to be commoned up and allocated the largest stated
  size of any of the symbols.  We don't do that -- if two different
  .o files each declared  int a[10],  you'll get two independent
  lumps of memory.  Hence "almost" above.

These calloc'd lumps (pseudo-bss spaces) are not added to the list
of sections extracted for the benefit of the closure-vs-itbl pointer
checks done by the garbage collector.  I don't think that matters.

These fixes need to be propagated to other formats too (viz, ELF).

This fixes the problem reported by ??? in which, on Windows,
   writeFile "foo" "bar" in GHCi gives a segfault.

This bug was so horrible to track down and fix that I have instituted
range checking in the relocation processing machinery.  The runtime
linker checks all locations it is patching to ensure they are within
a known segment before writing to them.  Hopefully this will pick up
any future problems.  The performance impact of this, assessed by
the time to start up GHCi, is unmeasureably small.