Use ActiveRecord to generate queries for specs

First of all, congratulations for the project as I find it very interesting.

Today I had the opportunity to dig a bit into the source code and in this Pull–Request you'll find out my thoughts, specifically about tests.

Parelation is about converting an HTTP request into a suitable ActiveRecord query, but the tests didn't reflect that. The highlight was more on the SQL, rather than showing which query the library should have come up with.

So, here's what I made:

1. First, I tried to give specs a better structure so that it's easy to recognize the input and the output (`criteria` and `ar_query` variables make this contrast really evident)
2. I constructed the queries via ActiveRecord API, calling `to_sql` after the query building

I believe the code has improved and to me it feels more readable. One added benefit is that, in this way, your tests won't break if there's some change in the way ActiveRecord construct queries.

What do you think? :smile: 
@meskyanichi I was just examining this, and it turns out that the `DirectionalQueryApplier` builds the sql via this query:

```ruby
%Q{"#{chain.arel_table.name}".? #{OPERATOR_MAPPING[operator]} ?}
```

The first parameter in the query is replaced with the column name, but it is replaced via single quotes (which I am not sure is the convention in SQL, since usually double quotes are used for table names).

So, we have two options here:

1. Simply use the single quote format on the spec, e.g.

  ```diff
  - .where(%Q{"tickets"."created_at" > ?}, "2014-01-01 00:00:00.000000")
  + .where(%Q{"tickets".'created_at' > ?}, "2014-01-01 00:00:00.000000")
  ```

2. Alternatively we might want to tweak the constructed query and avoid ActiveRecord parameter replacement, e.g. (pseudocode):

  ```diff
  - %Q{"#{chain.arel_table.name}".? #{OPERATOR_MAPPING[operator]} ?}
  + %Q{"#{chain.arel_table.name}"."#{criteria.column_name}" #{OPERATOR_MAPPING[operator]} ?}
  ```

  My only concern in this scenario would be exposure to SQL injection, or other security issues which are prevented by default by parameters. Supposedly here we should explore ways of sanitizing the input string.

What do you think if we stick with the first approach? The format is inconsistent with ActiveRecord's one, but the code is pretty clear and it seems like an acceptable tradeoff.