[lld-macho] Overhaul map file code

[lld-macho] Overhaul map file code

The previous map file code left out was modeled after LLD-ELF's
implementation. However, ld64's map file differs quite a bit from
LLD-ELF's. I've revamped our map file implementation so it is better
able to emit ld64-style map files.

Notable differences:
* ld64 doesn't demangle symbols in map files, regardless of whether
  `-demangle` is passed. So we don't have to bother with
  `getSymbolStrings()`.
* ld64 doesn't emit symbols in cstring sections; it emits just the
  literal values. Moreover, it emits these literal values regardless of
  whether they are labeled with a symbol.
* ld64 emits map file entries for things that are not strictly symbols,
  such as unwind info, GOT entries, etc. That isn't handled in this
  diff, but this redesign makes them easy to implement.

Additionally, the previous implementation sorted the symbols so as to
emit them in address order. This was slow and unnecessary -- the symbols
can already be traversed in address order by walking the list of
OutputSections. This brings significant speedups. Here's the numbers
from the chromium_framework_less_dwarf benchmark on my Mac Pro, with the
`-map` argument added to the response file:

             base            diff           difference (95% CI)
  sys_time   2.922 ± 0.059   2.950 ± 0.085  [  -0.7% ..   +2.5%]
  user_time  11.464 ± 0.191  8.290 ± 0.123  [ -28.7% ..  -26.7%]
  wall_time  11.235 ± 0.175  9.184 ± 0.169  [ -19.3% ..  -17.2%]
  samples    16              23

(It's worth noting that map files are written in parallel with the
output binary, but they often took longer to write than the binary
itself.)

Finally, I did further cleanups to the map-file.s test -- there was no
real need to have a custom-named section. There were also alt_entry
symbol declarations that had no corresponding definition. Either way,
neither custom-named sections nor alt_entry symbols trigger special code
paths in our map file implementation.

Reviewed By: #lld-macho, Roger

Differential Revision: https://reviews.llvm.org/D137368