Make authors define how they plan to use a subquery #96
Description
One foot-gun not covered by Yawn's type-safety is that one can write a subquery that returns multiple rows and use it in an equals restriction. This will lead to a runtime error in most databases (e.g. MySQL and CRDB). If Yawn makes authors define how they're using the subquery, then we can verify with the type system that the subquery isn't used in an invalid location
One way to do this is to change the type of the detached criteria builder based on how the author configures the subquery, so if they indicate in that it's a list, then we return a ListDetachedCriteria and for a unique result we return a UniqueDetachedCriteria. Then, we can verify that addEq only accepts UniqueDetachedCriteria objects.
It's worth noting that this is just codifying an expectation, something could still change at runtime that means that the query is no longer only returning one row and therefore break the assumption and cause an exception to be thrown.
See #95 for an example of where this caused confusion and an accidental switch to a less performant query that led to a regression.