RequirementMachine: Protocol atoms order before associated type atoms

If you have a same-type requirement like 'Self.Foo == Self' inside a
protocol P, we add a rewrite rule:

[P].Foo => [P]

Simplification turns this into

[P:Foo] => [P]

Previously, the order was backwards so we would end up with

[P] => [P:Foo]

Which would mess up the conformance information in the equivalence class map.

Author: slavapestov

lib/AST/RequirementMachine/RewriteSystem.cpp

@@ -393,9 +393,15 @@ Atom Atom::forConcreteType(CanType type, ArrayRef<Term> substitutions,
 
 /// Linear order on atoms.
 ///
-/// First, we order different kinds as follows:
+/// First, we order different kinds as follows, from smallest to largest:
 ///
-///   AssociatedType < GenericParam < Name < Protocol < Layout
+/// - Protocol
+/// - AssociatedType
+/// - GenericParam
+/// - Name
+/// - Layout
+/// - Superclass
+/// - ConcreteType
 ///
 /// Then we break ties when both atoms have the same kind as follows:
 ///

lib/AST/RequirementMachine/RewriteSystem.h

@@ -72,6 +72,17 @@ class Term;
 class Atom final {
 public:
   enum class Kind : uint8_t {
+    //////
+    ////// Special atom kind that is both type-like and property-like:
+    //////
+
+    /// When appearing at the start of a term, denotes a nested
+    /// type of a protocol 'Self' type.
+    ///
+    /// When appearing at the end of a term, denotes that the
+    /// term's type conforms to the protocol.
+    Protocol,
+
     //////
     ////// "Type-like" atom kinds:
     //////
@@ -93,13 +104,6 @@ class Atom final {
     ////// "Fact-like" atom kinds:
     //////
 
-    /// When appearing at the start of a term, denotes a nested
-    /// type of a protocol 'Self' type.
-    ///
-    /// When appearing at the end of a term, denotes that the
-    /// term's type conforms to the protocol.
-    Protocol,
-
     /// When appearing at the end of a term, denotes that the
     /// term's type satisfies the layout constraint.
     Layout,