Better @Table/@Selection composition: nested column groupings, enums, and more

[stephencelis]

The @Selection and @Table macros currently overlap in many ways, but there lacks a cohesive story. @Selection generates a nested Columns type that can used in a query to select from expressions, while @Table does not, even though it would be just as beneficial to do so.

And then we have @Table @Selection for combining this logic together for common table expressions, which can be queried like tables. But we should probably just bake everything into a single macro.

This PR explores a rethinking of @Table and @Selection to allow them to better compose together. Both macros now output most of the same functionality. There is just a small semantic difference.

@Table should be used for globally queryable table-like things. This includes:

• Database tables
• Virtual tables
• Database views

@Selection should be used for groups of columns. This includes:

• A set of columns selected in a query
• A common table expression that can be queried

With their functionality now almost entirely overlapping, we can compose them together. You can now group a bunch of a table's columns using @Selection:

@Selection
struct Timestamps {
  let createdAt: Date
  var updatedAt: Date
}

@Table
struct Reminder {
  let id: UUID
  let timestamps: Timestamps
}

(You can nest these selections arbitrarily deep.)

You can specify composite primary keys:

@Table
struct Enrollment {
  @Selection
  struct ID {
    let courseID: Course.ID
    let studentID: Student.ID
  }

  let id: ID
  // ...
}

You can even define database functions that take full tables/selections as arguments:

@DatabaseFunction
func isValid(_ reminder: Reminder) -> Bool {
  // Validate reminder...
}

Reminder.select { $isValid($0) }
// SELECT "isValid"("reminders".id, …)
// FROM "reminders"

Finally, we are introducing a new StructuredQueriesCasePaths trait, which allows for enum-based tables and selections, which can be used in all the ways above.

@CasePathable
@Table
enum TimelineItem {
  case note(Note)
  case photo(Photo)
  case video(Video)
}

[stephencelis]

Bikeshed opportunity: this is aliased to Columns, but named Selection here to distinguish itself better from TableColumns. Do we want to consider alternate naming, though to avoid overloading things with aliases?

[stephencelis]

Bikeshed opportunity: Should we call this TableColumnGroup for consistent prefixing?