This commit fixes 0d47edb6. Recently I hit the following: I was trying
to open the database via

	sqlite3.Open(dburl, sqlite3.OpenNoMutex)

i.e. by passing flags, but erroneously no OpenReadWrite or something
similar, and got

	"testdata/1.sqlite: bad parameter or other API misuse"

as the error.

The message was confusing because there is no "open" action in it, so
add the action to OpenError and the mesage becomes:

	"testdata/1.sqlite: open: bad parameter or other API misuse"

See full discussion for structure of error messages here:

https://github.com/gwenn/gosqlite/pull/14

open: Fix error message

By accident I was trying to open a non-existing database file and got
the following message:

	unable to open database file (unable to open database file)

which was not helpful.

By convention the error returned by a function should contain the
context passed to that function - the filename in Open case, the
operation performed and the error description. So

- teach OpenError to print filename of the opened database and the
  operation.
- don't duplicate the code in braces if we have the error message
  with the same text because they are often redundant.
- if we have only error code but not a message, still we have to include
  the filename and operation in the printed context.
- in the Open itself: always return OpenError on handling errors from
  sqlite3_open_v2 even if db == nil - instead of returning only Errno
  without any context.

Now the error in my case is:

	notfound.db: unable to open database file

( @gwenn requested to omit the ": open" (operation) probable because it
  duplicates error detail a bit )

/helped-by @gwenn

driver: Don't waste resources setting/being-notified up in progress handler if context cannot be canceled

driver: Don't waste resources setting/being-notified up in progress handler if context cannot be canceled

Please see https://github.com/mattn/go-sqlite3/pull/530 for similar
change. Here it is not additional goroutine but a callback setup which
will be called ever 100 ops. We can avoid that if we know that ctx
cannot be canceled.

Caveat: it will not be possible to retry on SQLITE_BUSY.

Add working cgo defaults for FreeBSD (#7)

To be fixed: cgocheck & panic

Still missing: StmtExecContext and StmtQueryContext

To be continued

It does not seem to be specify but it fails at runtime.