Ensure full LTO'd bitcode goes through the normal LTO pipeline instead of the thinlto pipeline

(Summarized from https://g-issues.fuchsia.dev/issues/517626589)

If we build an rlib compiled with -Clto=fat but use the bitcode in a link using -Clto=thin then we will hit this assertion in thinLTOInternalizeModule:

      if (GS == DefinedGlobals.end()) {
        // Also check the original non-promoted non-globalized name. In some
        // cases a preempted weak value is linked in as a local copy because
        // it is referenced by an alias (IRLinker::linkGlobalValueProto).
        // In that case, since it was originally not a local value, it was
        // recorded in the index using the original name.
        // FIXME: This may not be needed once PR27866 is fixed.
        GS = DefinedGlobals.find(
            GlobalValue::getGUIDAssumingExternalLinkage(OrigName));
        assert(GS != DefinedGlobals.end());
      }
    }
    return !GlobalValue::isLocalLinkage(GS->second->linkage());

It appears that when rust is driving the link that it will unconditionally pipe all bitcode through the thin lto pipeline. I believe this is incorrect for these reasons:

1. The fat lto pipeline doesn't emit module summaries in the first place (to be addressed in https://github.com/rust-lang/rust/pull/159029)
2. Full'fat lto'd bitcode should go through the normal full lto pipeline

Normally this would work if lld drives the link since lld knows how to dispatch which bitcode module goes through which pipeline. We should ensure rust does the same.

Trace the Rust-driven link path that unconditionally sends bitcode through the thin LTO pipeline, and compare it with lld's pipeline dispatch. Use the thinLTOInternalizeModule assertion and the fat-versus-thin LTO behavior described here as checks; done means full fat-LTO bitcode follows the normal full LTO pipeline while thin-LTO bitcode still uses thin LTO.