Add ColumnTypeScanType to driver

[ncruces]

Fix #198.

[ncruces]

@ngocphuongnb, can you test this please?

[ncruces]

I'm gonna merge this as:

1. this passes your unit test
2. like modernc (which you linked to) it supports the following pattern, which I've seen as a common usage

dest := make([]any, len(cols))
for rows.Next() {
	cols, err := rows.ColumnTypes()
	if err != nil {
		return err
	}

	for i, c := range cols {
		dest[i] = reflect.New(c.ScanType()).Interface()
	}

	err = rows.Scan(dest...)
	if err != nil {
		return err
	}
}

PR #197 would break this, be it because of "dynamic typing" or just NULLs in any column that's not []byte or any.

[ncruces]

With PR:

If you call rows.ColumnTypes() once, before calling rows.Next() you get types inferred based on the "declared type" of the column (if any). Here, I'm only committing to support STRICT tables, previously supported types used to tag time.Time, and BOOLEAN for bools. I don't go overboard with affinity rules: it's a straight "known names" list only. Other drivers seem to kinda agree.

Once you start iterating through rows, you get types based on the values. Here, I'm only committing to this rule: the scan type must be able to scan the value. I do take into account the column type, but I make no claim to pick the "best" type (whatever that means), or "most specific" type, or whatever, to scan the value. Just that it can scan the value, and is not too stupid.

If either these decisions turns out wrong, I'll tweak them. I'm pretty sure there's no right answer here, just heuristics.

[ngocphuongnb]

@ncruces Thank you for your great effort in making the decision and creating this PR.
The approach with ColumnTypeScanType is both creative and thoughtful, addressing the issue in a much more comprehensive and elegant way than my previous solution.
I really appreciate the time and consideration you put into crafting this improvement. Your work makes a significant difference. Thank you again!

[ncruces]

Thank you for your kind words!