The plugin id used here must match the one in plugin.xml or the test runner will fail to remove it when deployed.

The test was closing the database in the middle of an execute transaction. This would cause the transaction to fail because at the exit of the transaction handler a commit would be issued on a closed database. This fix moves the close to the success handler of the transaction so that the final close occurs after the transaction ends.

Additionally, the db variable is now obtained from the open callback instead of the function result, which is a more consistent pattern for async.

Finally, the close method was updated to fail if an attempt is made to call it while a transaction is active and a test was added to confirm this behavior.

According to the W3C spec, if a transaction failure callback *does not return false* then the error is propagated to a transaction failure. This means that if a transaction returns true, but more importantly, if it has no return value (undefined) then the error must propagate to the transaction. This fix explicitly requires false to correct the propagation.

A subsequent fix will address the fact that the original statement error is not propagated and is replaced here, but that is unrelated to this issue.

The aforementioned methods receive errors as string messages from the native layer, so these strings must be wrapped in a regular `Error` type before passing on to API callbacks.

This fix also makes 2 minor changes to open:
1) remove a semicolon per doc convention
2) only call the success callback if there is one (in case the default handler that logs is ever removed)

Sometimes the native layer returns errors as {message:string, code:number} and other times as just a string. This fix wraps key places to ensure that errors returned through the API always conform to SQLError per the API contract documented in the W3C spec.

In short, errors consistently have a message and code now and propagate from statement failure up to the transaction.

Moving data between JavaScript and native is extremely slow, especially for binary which Cordova has to base64 encode and then transmit over XHR or as an URL parameter. The last thing we want to do is send more data. For some reason SQL statements and their parameters were being sent twice because they were duplicated to a `query` member. That member was only used by the iOS plugin, so this fix removes it and updates the iOS plugin to use the sql and params members like the others.

Additionally, the iOS plugin is updated to handle unsupported types during binding and a test was added to verify.

The regex function for iOS was reading arguments before checking that the correct number were specified.

This fix enables end-to-end encoding of binary data using strings.

Strings with Unicode values like `\u0000` were being truncated because the string constructor was using a null terminator to determine size instead of the stored byte length. The fix uses a different constructor and the stored byte length so that the full length string is returned.

Parameters use `,` not `;`.

If executeSql is called on a finalized transaction it should throw. If it does not, timing errors get a lot harder to debug. ES6 promises, for example, generally execute on the next tick and then it becomes unclear why a statement fails to execute.

Web SQL doesn't actually support storing binary data in SQL blobs using the SQLite blob methods. It serializes binary data using strings with the SQLite text methods which results in data not being stored as a blob. This can be problematic in Cordova if you need to work with existing SQLite databases.

This change adds more robust support for binary serialization. `SQLBlob` objects can be used in statements and these will be converted to a `sqlblob` URI with base64 or URL encoded data that is unpacked on the native side and stored as a proper binary blob.

When reading a blob back from the native side, the previous behavior was to return the blob as base64. Now, the blob can be decoded as a `SQLBlob` object which can then be unpacked in JavaScript to base64, ArrayBuffer, or binary string.

  tx.executeSql('INSERT INTO test_table VALUES (?)', [new SQLBlob(arrayBuffer)]);

  tx.executeSql("SELECT foo FROM test_table", [], function(tx, res) {
    var blob = new SQLBlob(res.rows.item(0).foo);
    blob.toBase64();
    blob.toBinaryString();
    blob.toArrayBuffer();
  });

Tests were added to verify the behavior and to demonstrate usage.

Only iOS and Android were updated. Windows Phone did not previously have blob support; saving for a future update.