Support custom queries in builder

[Serdnad]

This is a first attempt at addressing #402 , and implements support for building simple queries through the use of handwritten SQL like so:

users = Users.where("age > ?", 18) # == where(:age, :gt, 18)

with the intention of providing a way to support more sophisticated queries, such as

users = User.where("LOWER(name) = ?", name)

and even database specific features, like checking for membership in an array using Postgres:

users = User.where("? = ANY(trusted)", id)

The current implementation only allows one argument per query, but it should be rather straightforward to extend this to allow multiple args per query, if that's desired.

A simple spec is included for each DB adapter.

Note: I've opened this PR as a draft because I also intend to include an addition to the docs, but wanted to make this available for review as early as possible.

[Serdnad]

Tweaked the implementation to allow for a nil value, to support running a raw SQL string with no parameter substitutions.

[Serdnad]

Added specs for #where, #or, and #and as requested, and updated Postgres to use $ as a placeholder instead of ?.

[drujensen]

lgtm. I am wondering if this supports an array as a parameter where("id in ?", [1, 2, 3])

[Blacksmoke16]

@Serdnad Does your @placeholder stuff work? AFAIK $ on its own is not a valid PG placeholder. It would need the index value to work correctly.

[Serdnad]

@Blacksmoke16 This placeholder just tells the assembler that there's a placeholder in the query, so that the assembler can then replace this with the proper, final placeholder, such as $1 in the case of Postgres. This way, you can chain several where queries without having to manually keep track of the index. This is also why my previous implementation worked even when ? was used with PG, even though PG doesn't actually use ?, because the assembler would then replace it with the correct placeholder.

@drujensen That's a good point. I just checked, and it seems like the array would have to be formatted as (1, 2, 3) for that to work. Would it make sense to treat this as a separate issue, or do you think that should be included before merging?

Edit: Actually, I'm not so sure about that last point. I'll do some testing.

[drujensen]

@Serdnad It can be treated as a separate issue. If @Blacksmoke16 approves, we can merge.

[robacarp]

@Serdnad this looks great!

[Serdnad]

Thanks @robacarp ! This turned out very differently than what I was initially looking for, but definitely for the better. Huge thanks for all the input and feedback from all of you :)