Support for the single/at-least-one row pattern in sqlitex.Execute and friends.

[flowchartsman]

Follow-on to #85

sqlitex.Execute and friends are one of the nicer parts of this library, IMHO, since they provide a nice level of abstraction over the scan process without being too magical or cumbersome. I especially enjoy how well the FS variants can coexist with package embed allowing for a nice separation between SQL and source, while overloading the fs path as an extra level of organization.

The only rough edge from my experience is identifying queries that return a single result from those which do not. Currently, the only support for this exists in the form of Result* methods such as sqlitex.ResultInt, however these only work with statements, which leaves a lot of boilerplate for the user in terms of setting up query parameters. To do something similar withExecute, the user needs to

1. Inspect their target value, (difficult for scalars, since a zero value could be explicit)
2. Use a pointer and initialize it on finding a row
3. Record whether or not the ExecOptions.ResultFunc has been called using another value outside of the closure and an update of the value inside of the closure:

called :=false // tracking value
err = sqlitex.ExecuteFS(conn, sqlFS, "path/to/embedded.sql", &sqlitex.ExecOptions{
	Named: args{
		":key": key,
	},
	ResultFunc: func(stmt *sqlite.Stmt) error {
		if called {
                     return errors.New("more than one value returned")
                 }
		called := true
		r := stmt.ColumnReader(0)
		// do something with r and other values here
	},
})
if err != nil {
	// handle any error from Execute, including "more than one value returned"
}
if !found {
	// handle handle "no results returned"
}

This is a common enough use case that it would be great if we could automate it.

There are a couple different ways this could be done that I've proposed so far:

• a boolean field on ResultFunc
• a SingleRow family of functions that uses closures to automate the above.

But there may be more, so I'd love to discuss it here.