Implement SQLite functions and aggregates, update SQLite encoder and decoder APIs

[joeybright]

Fixes #47

• Updates the SQLite encoding and decoding APIs to separate raw SQLite values from encoding and decoding from returned rows from a query. Examples of the new API in use can be seen in the test suite. This API was discussed in the Discord channel for the SQLite functionality.
• Implements custom SQLite functions with the new Sqlite.Function module. Custom SQLite functions can have an arbitrary amount of arguments. They also leverage the new encoding / decoding APIs to make sure that values given to the custom function are properly decoded and the return values from the functions are encoded as values SQLite can understand.
• Implement custom SQLite aggregate functions, too, with the new Sqlite.Aggregate module. This includes support for aggregate functions over a window query. The API for constructing the aggregate function is very similar to custom SQLite functions.
• Tests for both custom SQLite function and aggregates. The test cases are quite contrived so I'm open to more closer to real life use-cases if we want to have a more robust test suite if I'm given some examples!

[robinheghan]

Is it possible to throw an exception here in order to return a detailed Error? Would be helpful, I think, to see why func(jsonArgs) !== Ok

[robinheghan]

Same thing here. When result === Err, we'd ideally want the user to get that Err

[joeybright]

@robinheghan I can do a little more investigation on this, but my understanding is that because this function (and the one above) is called by SQLite outside of the Gren runtime, it can't interact with the Gren runtime. If we throw in this function in the kernel code, I believe the program will just crash? We aren't calling this function within the confines of the try catch block in the register function - SQLite is calling the wrappedFunc which, when passed as a variable to .register, I assume evokes it outside of the block its in when its registered.

It's easy enough for me to try, though. I'll do so when I get the chance and report back.

Another option we can do here is allow the user to pass an optional onErr function when registering the SQLite function or aggregate function. It'd have the error as an argument and the function just return a Sqlite.Encode.Value, so SQLite doesn't throw when this function is called on an error state. The only thing it'd really allow someone to do is return a value other than null in the case of an error, which may be helpful and does give them a bit more access to possible errors.

[robinheghan]

This explination makes sense. See what happens if you throw an exception, and leave the code as is if it doesn't work out.