SHF_LINK_ORDER's original semantics make upgrade difficult

[Fangrui Song]

For your convenience, the agreed semantics of SHF_LINK_ORDER is attached:

https://groups.google.com/d/msg/generic-abi/_CbBM6T6WeM/eGF9A0AnAAAJ

     SHF_LINK_ORDER

### Original semantics
        This flag adds special ordering requirements for link editors. The
        requirements apply to the referenced section identified by the sh_link
        field of this section's header.  If this section is combined with other
        sections in the output file, the section must appear in the same
        relative order with respect to those sections, as the referenced
        section appears with respect to sections the referenced section is
        combined with.

        A typical use of this flag is to build a table that references
        text or data sections in address order.

### Extended semantics for metadata sections
        In addition to adding ordering requirements, SHF_LINK_ORDER indicates
        that the section contains metadata describing the referenced section.
        When performing unused section elimination, the link editor should
        ensure that both the section and the referenced section are retained
        or discarded together. Furthermore, relocations from this section
        into the referenced section should not be taken as evidence that the
        referenced section should be retained.

Say we have a monolithic metadata section (.foo) associated to a text section.
The metadata section is only referenced by the associated text section.  If we
want to "upgrade" the metadata section to SHF_LINK_ORDER in the future (to get
--gc-sections functionality with fragmented .foo sections), unfortunately the
original semantics make the design space narrow.

For compatibility reasons, we still have some object files with
non-SHF_LINK_ORDER monolithic .foo .  New .foo have the SHF_LINK_ORDER flag.
However, mixed SHF_LINK_ORDER and non-SHF_LINK_ORDER sections have an issue with
the linked-to order requirement (Original semantics). In practice, linkers
forbid a mix.

GNU ld: .gcc_except_table has both ordered [.foo' in a.o] and unordered [.foo' in b.o] sections
LLD is more relaxed, but it does not allow non-contiguous SHF_LINK_ORDER sections: a.o:(.foo): SHF_LINK_ORDER sections in .foo are not contiguous
   (https://reviews.llvm.org/D77007 )

In many cases, .foo doesn't really need original semantics and .foo can be
combined in an arbitrary order. What can we do to make such "upgrade" feasible?
The current design simply requires such metadata section to be designed with
SHF_LINK_ORDER in mind in the very beginning.