Zero size sections are common even during regular build on MacOS. For
instance:

```
$ ar -xv libHSghc-prim-0.6.1.a longlong.o
$ otool -l longlong.o
longlong.o:
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
 0xfeedfacf 16777223          3  0x00           1     2        176 0x00002000
Load command 0
      cmd LC_SEGMENT_64
  cmdsize 152
  segname
   vmaddr 0x0000000000000000
   vmsize 0x0000000000000000 <-- segment size = 0
  fileoff 208
 filesize 0
  maxprot 0x00000007
 initprot 0x00000007
   nsects 1
    flags 0x0
Section
  sectname __text
   segname __TEXT
      addr 0x0000000000000000
      size 0x0000000000000000 <-- section size = 0
    offset 208
     align 2^0 (1)
    reloff 0
    nreloc 0
     flags 0x80000000
 reserved1 0
 reserved2 0
       cmd LC_BUILD_VERSION
   cmdsize 24
  platform macos
       sdk 10.14
     minos 10.14
    ntools 0
```

The issue of `mmap`ing 0 bytes was resolved in !1050, but the problem
remained. These 0 size segments and sections were still allocated in
object code, which lead to failed `ASSERT(size > 0)` in
`addProddableBlock` further down the road.

With this change zero size segments **and** sections are not
mapped/allocated at all.

Test plan:

1. Build statically linked GHC.

2. Run `ghc --interactive`. Observe that REPL loads
successfully (which was not the case before).

3. Load several more compiled hs files into repl. No failures.