Better behavior from statement.run(undefined)

Let's say you prepare a statement with no parameters, and .run() it to
completion. Now the 'status' field on the Statement is SQLITE_DONE.

Now let's say that you run it, accidentally calling
  statement.run(undefined, callback)
instead of leaving out the first argument or passing an empty array.

The Baton returned by Bind<RunBaton> will have a parameters array with a
single NULL.

Then Work_Run will invoke stmt->Bind with this one-element array, while
stmt->status is still SQLITE_DONE.

Before this patch, the for loop in stmt->Bind would execute once, not
calling any bind functions, but still execute the
"stmt->status != SQLITE_OK" check. Since status is SQLITE_DONE, this
will cause the stmt->Bind to return false and for Work_Run to skip the
actual call to sqlite3_step.

However, since stmt->status is *still* SQLITE_DONE, Work_AfterRun will
report success.

It is arguably a bug to pass undefined in this case anyway, but the
current behavior where run() reports success without actually executing
the method is confusing.  (Especially when things work as expected on
the FIRST call to run(), because the initial status value is SQLITE_OK.)
Merge pull request #355 from glasser/run-undefined

Better behavior from statement.run(undefined)