Nearly all uses of `uniqCompareFS` are dubious and lack a non-determinism justification

$ rg uniqCompareFS
utils/haddock/haddock-api/src/Haddock/Interface/Specialize.hs
185:   compare (NameRep fs1) (NameRep fs2) = uniqCompareFS fs1 fs2

compiler/GHC/Iface/Ext/Types.hs
308:      = mconcat [uniqCompareFS c0 c1, uniqCompareFS t0 t1]

compiler/GHC/Cmm/CLabel.hs
326:    uniqCompareFS c1 c2 `thenCmp`
331:    uniqCompareFS a1 a2 `thenCmp`
338:    uniqCompareFS b1 b2

compiler/GHC/Core/TyCo/Rep.hs
197:  compare (StrTyLit x) (StrTyLit y)   = uniqCompareFS x y

compiler/GHC/Core/Opt/Monad.hs
550:cmpEqTick (RuleFired a)                 (RuleFired b)                   = a `uniqCompareFS` b

compiler/Language/Haskell/Syntax/Lit.hs
166:  compare (HsIsString _ s1)   (HsIsString _ s2)   = s1 `uniqCompareFS` s2

compiler/GHC/Tc/TyCl.hs
4171:    cmp_fld (f1,_) (f2,_) = flLabel f1 `uniqCompareFS` flLabel f2

compiler/GHC/Data/FastString.hs
26:--       * O(1) but non-deterministic with Unique comparison (`uniqCompareFS`)
91:        uniqCompareFS,
218:--    * by unique: non-deterministic, O(1). Cf uniqCompareFS    and NonDetFastString.
245:-- If you don't care about the lexical ordering, use `uniqCompareFS` instead.
256:uniqCompareFS :: FastString -> FastString -> Ordering
257:uniqCompareFS fs1 fs2 = compare (uniq fs1) (uniq fs2)
262:-- `uniqCompareFS` (i.e. which compares FastStrings on their Uniques). Hence it
269:   compare (NonDetFastString fs1) (NonDetFastString fs2) = uniqCompareFS fs1 fs2

compiler/GHC/Unit/Types.hs
293:  u1 `compare` u2 = instUnitFS u1 `uniqCompareFS` instUnitFS u2

Except for compiler/GHC/Data/FastString.hs, all of these files contain mentions of uniqCompareFS for which I couldn't immediately see how they would not affect the compiler output.

All of these should use lexicallyCompareFS. Heck, we should add back the Ord FastString instance and make it lexicallyCompareFS and use NonDeterministicFastString if we need the faster Unique-based instance.