Order a preprocessing storage's element types deterministically

The storage type's element list was built by inserting into a DenseSet<Type>
and then copying the set out. Type is a pointer wrapper, so the set hands its
elements back in the order of their addresses, and that order is not stable
from one run to the next.

The order is not cosmetic: the element list is part of the __preprocessing
function's signature and fixes which memref each store and load site indexes,
so permuting it produces a different module for the same input. A storage with
one element type could not show this; a storage holding several -- plaintexts
next to prepared linear transformations -- can.

Collect the types in first-occurrence order instead, which is what the nearby
uniqueElementTypes() helper already documents as the intended contract.

Author: AlexanderViand

lib/Transforms/SplitPreprocessing/SplitPreprocessing.cpp

@@ -378,13 +378,13 @@ struct SplitPreprocessingPass
     }
 
     // Create a preprocessing.storage type with the set plaintext types
-    DenseSet<Type> encodeTypesDeduped;
+    // Preserve first-occurrence order as it determines storage field indices.
+    SmallVector<Type> encodeTypes;
     for (Operation* input : analysis.encodeOps) {
-      encodeTypesDeduped.insert(
-          getElementTypeOrSelf(input->getResult(0).getType()));
+      Type encodeTy = getElementTypeOrSelf(input->getResult(0).getType());
+      if (!llvm::is_contained(encodeTypes, encodeTy))
+        encodeTypes.push_back(encodeTy);
     }
-    SmallVector<Type> encodeTypes(encodeTypesDeduped.begin(),
-                                  encodeTypesDeduped.end());
     auto storageTy =
         preprocessing::PreprocessingStorageType::get(context, encodeTypes);