Check the number of supplied parameters against what the statement expects

Panicking here is not a good idea, and an explicit error message should
be a lot more helpful to the user as well.
Fix handling of CommandComplete response to SimpleQuery

The previous coding in simpleQuery was slightly misguided; it was
written under the assumption that CommandComplete would only be
sent after ErrorResponse, which, as pointed out in #186, is simply
not true.  CommandComplete should only be received there as a
response to a query which was successfully executed, but did not
return any results.  This also means that we return a nil error
*and* a nil rows to database/sql, which would either panic (if the
user calls Rows.Close), or leak the connection (if he doesn't).

While any program using Query to execute such queries will likely
be experiencing problems already, there's no reason to completely
break them.  To fix the problem, we return a rows object which has
its "done" flag already set to allow the user to close the Rows
object from database/sql to avoid leaking connections.  Also add a
test case to check that we consistently allow both types of queries
through both Query and Exec, both with and without parameters.