Statement shouldn't inherit from Hashable

We made `Statement: Hashable` for convenience in holding onto statements
in a shared key for SQLiteData, but that isn't really necessary, since
we can always call out to the underlying query fragment to get a
hashable value.

This conformance unfortunately can cause bugs, including `==` resolving
to the equality operator when a query operator was expected. Another bug
is that `@Table @Selection` types conform to `Statement`, and this
equatable implementation was preferred over the default synthesized
version, making `Table` values equatable strictly by the underlying
query, which meant `@Ephemeral` fields weren't taken into account at
all.

With 0.20.0, all `@Table` applications introduced a `Statement`
conformance, and so this issue becomes much more widespread.

While this change can break SQLiteData if someone upgrades
StructuredQueries before upgrading SQLiteData with the changes from
pointfreeco/sqlite-data#245.

Author: stephencelis

Sources/StructuredQueriesCore/Statement.swift

@@ -1,5 +1,5 @@
 /// A type that represents a full SQL query.
-public protocol Statement<QueryValue>: QueryExpression, Hashable {
+public protocol Statement<QueryValue>: QueryExpression {
   /// A type representing the table being queried.
   associatedtype From: Table
 
@@ -15,13 +15,3 @@ extension Statement {
     "(\(.newline)\(query.indented())\(.newline))"
   }
 }
-
-extension Statement {
-  public static func == (lhs: Self, rhs: Self) -> Bool {
-    lhs.query == rhs.query
-  }
-
-  public func hash(into hasher: inout Hasher) {
-    hasher.combine(query)
-  }
-}

Tests/StructuredQueriesTests/EphemeralTests.swift

@@ -17,6 +17,10 @@ extension SnapshotTests {
         """
       }
     }
+
+    @Test func equality() {
+      #expect(TestTable(displayName: "Blob Jr") != TestTable(displayName: "Blob Sr"))
+    }
   }
 }