runSelectReturningOne should not return Nothing for more than one row

As asked on IRC, creating an issue for discussion.

`runSelectReturningOne` returns `Nothing` when more than one row matches the query. https://github.com/tathougies/beam/issues/268 states this is by design.

I claim that returning `Nothing` when more than one row is returned is a risky choice. It's correct to state the row ordering may not be defined and non-determinism may result, but returning `Nothing` signifies there are no rows that match the given constraints. That's likely to lead code to attempt to create a row and then fail either with a database constraint failure, or to further exacerbate the duplicate row problem. Secondly, a lot of other ORMs and database layers do not behave like this. Be it an OO `.first` or a functional `getFirst`, they often tack on a `LIMIT 1` and get on with it. `runSelectReturningOne`, while not modifying the query to optimize with a `LIMIT 1`, shouldn't at least behave in an unexpecting manner. I, for one, leaned towards `runSelectReturningOne` to not have to do `listToMaybe`, and didn't think twice whether there are or aren't duplicate rows.

Cheers.