[PECOFF] Only COMDAT symbols are allowed to be dead-stripped.

We should dead-strip atoms only if they are created for COMDAT symbols. If we
remove non-COMDAT atoms from a binary, it will no longer be guaranteed that
the binary will work correctly.

In COFF, you can manipulate the order of section contents in the resulting
binary by section name. For example, if you have four sections
.data$unique_prefix_{a,b,c,d}, it's guaranteed that the contents of A, B, C,
and D will be consecutive in the resulting .data section in that order.
Thus, you can access B's and C's contents by incrementing a pointer pointing
to A until it reached to D. That's why we cannot dead-strip B or C even if
no one is directly referencing to them.

Some object files in the standard library actually use that technique.

git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@193017 91177308-0d34-0410-b5e6-96231b3b80d8
Fix bug that CompareAtoms::compare is not transitive.

This patch fixes a bug in r190608. The results of a comparison function
passed to std::sort must be transitive, which is, if a < b and b < c, and if
a != b, a < c must be also true. CompareAtoms::compare did not actually
guarantee the transitivity. As a result the sort results were sometimes just
wrong.

Consider there are three atoms, X, Y, and Z, whose file ordinals are 1, 2, 3,
respectively. Z has a property "layout-after X". In this case, all the
following conditionals become true:

  X < Y because X's ordinal is less than Y's
  Y < Z because Y's ordinal is less than Z's
  Z < X because of the layout-after relationship

This is not of course transitive. The reason why this happened is because
we used follow-on relationships for comparison if two atoms falls in the same
follow-on chain, but we used each atom's properties if they did not. This patch
fixes the issue by using follow-on root atoms for comparison to get consistent
results.

Differential Revision: http://llvm-reviews.chandlerc.com/D1980

git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk@193029 91177308-0d34-0410-b5e6-96231b3b80d8