Support the use of unions in subqueries

[gwynne]

These changes are now available in 3.30.0

Adds support for the use of UNION queries within subqueries. Unfortunately, thanks to iffy design choices on my part in the original SQLUnion implementation, the usage is slightly awkward. Example usage:

try await db.update("foos")
    .set(SQLIdentifier("bar_id"), to: SQLSubquery
        .union { $0
            .column("id")
            .from("bars")
            .where("baz", .notEqual, "bamf")
        }
        .union(all: { $0
            .column("id")
            .from("bars")
            .where("baz", .equal, "bop")
        })
        .finish()
    )
    .run()

This generates the following query:

UPDATE "foos"
SET "bar_id" = (
        SELECT "id" FROM "bars" WHERE "baz" <> "bamf"
    UNION ALL
        SELECT "id" FROM "bars" WHERE "baz" = "bop"
)

Unfortunately, it is not possible to chain .union() when using SQLSubquery.select(_:); the call chain must start with SQLSubquery.union(_:).

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (9afdc96) to head (9b9f663).

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #178   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           97        98    +1     
  Lines         2551      2565   +14     
=========================================
+ Hits          2551      2565   +14     

Files	Coverage Δ
.../Builders/Implementations/SQLSubqueryBuilder.swift	100.00% <100.00%> (ø)
...Kit/Builders/Implementations/SQLUnionBuilder.swift	100.00% <100.00%> (ø)
...it/Builders/Prototypes/SQLCommonUnionBuilder.swift	100.00% <100.00%> (ø)
...urces/SQLKit/Expressions/Clauses/SQLSubquery.swift	100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes

[gwynne]

API breakage notes:

• The change from SQLSelectBuilder to any SQLSubqueryClauseBuilder in the parameters for the SQSelectBuilder extension methods is an API break but has no actual effect, as SQLSelectBuilder provides no API that the protocol doesn't (or at least, none that can be used in the relevant context).
• The removed methods on SQLUnionBuilder are now provided as extension methods on the SQLCommonUnionBuilder protocol instead.

[MahdiBM]

If you're sure about the API breakage.

[gwynne]

I am, actually 🙂. Look at the definition of SQLSelectBuilder. The only method of its own it defines is an initializer, and the SQLQueryBuilder and SQLQueryFetcher methods aren't callable within sub-builder closures (they're all asynchronous; there's nowhere to go with an ELF (anyone calling .wait() in that context frankly deserves what they get) and you can't await in a non-async closure).