Better error catching on query types

The current type parsers are a bit funky and could use a little tightening up. This is best explained with some examples:

# Assuming `favorite_languages` is `Array(String)`
# This still compiles, but throws a `PQ::PQError`
UserQuery.new.favorite_languages("Crystal")

# Assuming `prices` is `Array(Float64)`
# This compiles, and is technically ok since this would be converted just fine.
# But should it?
ItemQuery.new.prices(["100"])

# Assuming `heart_count` is `Int32`
# This also compiles but is ok since it can be parsed
PostQuery.new.heart_count("5")
# This compiles, but throws an error
PostQuery.new.heart_count("five")

Since we want to focus on type safety, it's important that we lock these down the best we can, and use compile-time errors where possible.

ref: https://github.com/luckyframework/avram/pull/151#discussion_r305098032

Start with the query type parsers and the examples in this issue, then read the linked discussion in pull request 151 for the existing type-safety context. Establish which mismatched arguments should fail at compile time versus be converted, and verify that invalid values no longer surface as unexpected PQ::PQError exceptions.