Fix Scan's handling of type that implements RowScanner and CompositeIndexGetter

[jaltavilla]

This fixes issue #2609

[jackc]

According to Claude:

1. RowToMap breaks on any single-column query. rows.go:542 scans through one dest that implements RowScanner (*mapRowScanner). With one column the counts now match, so the RowScanner branch is never reached and pgx tries to plan a scan of the column into the map type:

can't scan into dest[0] (col: a): cannot scan text (OID 25) in text format into *pgx.mapRowScanner
So pgx.CollectRows(rows, pgx.RowToMap) on select 'foo'::text as a fails. Passes on master, fails on the PR branch. Two columns still work — which is why the existing suite doesn't catch it.

2. Panic when Scan is called with zero destinations. rows.go:247 evaluates dest[0] before checking len(dest):

panic: runtime error: index out of range [0] with length 0
github.com/jackc/pgx/v5.(*baseRows).Scan rows.go:247
rows.Scan() against a 1-column result returns a clean "number of field descriptions must equal number of destinations" error on master.

3. Every single-column RowScanner stops working — the general form of Select single values #1, and a public API behavior break. A user type whose ScanRow does rows.Scan(&rs.field) no longer has ScanRow called for a one-column result; it gets cannot scan text (OID 25) in text format into *T instead. That's broader than RowScanner takes precedence over CompositeIndexScanner incorrectly #2609 asks for, and there's no opt-out.

[jaltavilla]

I've re-implemented this to only override the use of RowScanner in the specific case that the destination is a composite and the field is known to be a composite.

I also added a couple tests for cases the prior pr broke to help future contributors.