Implement FromSql for tuples up to length 4

[benesch]

This makes it very ergonomic to decode the results of a query like

SELECT (1, 'a')

where (1, 'a') is returned as an anonymous record type.

The big downside to this approach is that only built-in OIDs are
supported, as there is no way to know ahead of time what OIDs will be
returned, and so we'll only have metadata for the built-in OIDs lying
around.

Fix #310. Also related to #366 and #565.

[AtsukiTak]

Looks great! I'm very interested in this feature!
It would be nice for me if it is also implemented for tuples more than 5 items under some feature gate just like diesel's 32-column-tables, 64-column-tables and 128-column-tables features. 😄

I hope this PR will be merged!

[skreborn]

@sfackler Is there anything - other than a rebase - that prevents this from being merged? I agree that at least 8 tuple items should be supported, but adding huge numbers seems excessive for a first implementation. We can always add more (behind feature flags) later, building on this PR.

Right now, we're forced to implement this ourselves, and it would help tremendously to have built-in support for tuples.

[WGH-]

This is a useful feature.

Maybe not so on its own: who writes SELECT (foo, bar) ... instead of SELECT foo, bar, after all?

But if you do things like SELECT t1, array_agg((t2.foo, t2.bar)) FROM t1 NATURAL JOIN t2 GROUP BY t1.id, support for the record type suddenly becomes much more useful. This example would also require support for the record[] type, but that would be the next step.