feat: support boolean values encoded as text

[emizzle]

status-go, owing to its use of a version of sqlcipher that uses a version of sqlite previous to 3.23.0, sometimes inserts (“0”, 0, false, FALSE, “false”, “FALSE”) or (“1”, 1, true, TRUE, “true”, “TRUE”) for boolean values in the database. Here, we are able to properly decode text and integer encodings of booleans in the database into Nim's bool type.

feat: add unit tests for sqlite boolean literals support

NOTE

This is a draft PR while we wait for input on alternative approaches.

@arnetheduck (I can't seem to be able to tag @Zahary, @cheatfate, @stefantalpalaru) this PR is the only way that we figured out how to accomplish what we were trying to do, and were hoping to get any suggestions for alternative approaches. status-im/nim-status#157 encapsulates the issue in its entirety, but for summary's sake, the issue we experienced is that status-go uses a version of sqlcipher that uses an old version of sqlite that does not properly support boolean literals in SQL syntax. sqlite (< 3.23.0), instead of interpreting boolean literals in SQL syntax as integers, stores them as strings in the boolean columns. This causes issues on read operations, where nim-sqlcipher is expecting an int (booleans are stored as 0/1), but instead is getting a string.

What we were hoping to do, was to leave the nim-sqlcipher lib as is owing to the fact that the responsibility doesn't fall on sqlcipher to fix issues caused by legacy sqlite versions. Instead, we were were hoping to handle this case in a consumer library such as nim-status. However, we were not able to figure out a way to do this, because we couldn't seem to find a way to "inject" a consumer proc in to nim-sqlcipher without introducing more complexity and sources of failure.

Is what we did satisfactory, or would you suggest accomplishing what we were trying to do in another manner?