[#1725] Add tests for when searching/deleting elements passing invalid filters
[#1725] Adds IDataStore interface and extension point to change WHERE clauses

I prefered to extend on `where` instead of `search_data` and `delete_data`
separately to keep the extension code DRY.

The IDataStore extensions' `where` methods are called with the `filters` dict
received from the user. They must check if there's any filter they want to
process and create a `clause` list with elements as tuples following the
pattern:

    (SQL_CLAUSE, PARAM1, PARAM2, ...)

The SQL_CLAUSE can be anything valid on the WHERE clause, for example
`AVG(score) > %s AND AVG(score) < %s`. You have to substitute any user-defined
parameters for `%s`, doesn't matter what their type is (int, string, ...).
Then, for each `%s` inside SQL_CLAUSE, you need to add one PARAM. For example:

    ('AVG(score) > %s AND AVG(score) < %s', 10, 20)

This pattern is needed to be able to sanitize user input and avoid SQL
Injections.

After that, you'll need to delete every key from the `filters` dict that you've
processed. Following our example, you'll have to:

    del filters['score_between']

We need this because we validate the filters' column names against the
DataStore resource's column names. Any filter on a column that doesn't exist on
the resource is invalid and raises an error. If you didn't remove
`filters['score_between']`, you'll receive a "Field 'score_between' doesn't
exist" error.

This is done to give the user a friendlier error message, and avoid another
possible SQL Injection vector.
[#1725] Forgot to import ckan.plugins
[#1725] Custom filters should be added inside parenthesis

The extensions can get a single filter (e.g. "age_not_between") and create two
WHERE clauses (e.g. "age < %s OR age > %s"). To avoid hard-to-track bugs
related to the operator precedence in Postgres, we add every custom filter
inside parenthesis.
[#1725] Filters received shouldn't be modified

This means that if the user sends us:

    'filters': { 'age_between': [20, 30] }

We should return that unmodified in the query result, even though internally
that might be translated to something else or removed.
[#1725] Guarantee that tests fail for the correct reason
[#1725] Add test to guarantee that every field in datastore_search is valid
[#1725] Fix exception caught when there's no CKAN_CURRENT_URL

When we try to get a key from a dict and it doesn't exist, a KeyError is
raised, not a TypeError.
[#1725] Refactor search_data()'s sort to accept an array

We'll need this to allow extensions to add new clauses to it.
[#1725] Catch exception thrown when there's no toolkit.request

I have changed this on 3fed29c, but got the following traceback:

```
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/usr/lib/ckan/default/src/ckan/ckanext/datastore/tests/test_interface.py", line 74, in test_filters_sent_arent_modified
    filters=filters.copy())
  File "/usr/lib/ckan/default/src/ckan/ckan/new_tests/helpers.py", line 91, in call_action
    return logic.get_action(action_name)(context=context, data_dict=kwargs)
  File "/usr/lib/ckan/default/src/ckan/ckan/logic/__init__.py", line 414, in wrapped
    result = _action(context, data_dict, **kw)
  File "/usr/lib/ckan/default/src/ckan/ckan/logic/__init__.py", line 530, in wrapper
    return action(context, data_dict)
  File "/usr/lib/ckan/default/src/ckan/ckanext/datastore/logic/action.py", line 339, in datastore_search
    result = db.search(context, data_dict)
  File "/usr/lib/ckan/default/src/ckan/ckanext/datastore/db.py", line 1141, in search
    return search_data(context, data_dict)
  File "/usr/lib/ckan/default/src/ckan/ckanext/datastore/db.py", line 947, in search_data
    _insert_links(data_dict, limit, offset)
  File "/usr/lib/ckan/default/src/ckan/ckanext/datastore/db.py", line 848, in _insert_links
    urlstring = toolkit.request.environ['CKAN_CURRENT_URL']
  File "/usr/lib/ckan/default/src/ckan/ckan/lib/maintain.py", line 75, in custom__getattr__
    depricated = __old_getattr__(self, '__depricated_properties__')
  File "/usr/local/lib/python2.7/dist-packages/paste/registry.py", line 137, in __getattr__
    return getattr(self._current_obj(), attr)
  File "/usr/local/lib/python2.7/dist-packages/paste/registry.py", line 197, in _current_obj
    'thread' % self.____name__)
TypeError: No object (name: request) has been registered for this thread
```
[#1725] Move validations to IDataStore's validate_query() method

This commit is the first step towards moving all validations of the received
`data_dict` to a single place. This was the easiest way I could think of to
allow extensions to modify our validation rules.

Every IDataStore extension should implement a `validate_query()` method that
receives the context, the data_dict, and the list of fields the current
resource has. The data_dict is a copy, so the extension is able to mess with it
without problems.

Inside that method, the extension will check everything it understands (e.g.
filters, fields, sorts). When finding something, it should remove it from the
data_dict. In the end, return the data_dict with everything it understands
removed. This new data_dict will be passed to the next extension.

After we do this with every extension available, we expect to have a data_dict
with empty values. For example:

```
    # Before calling
    data_dict = {
        'fields': ['age', 'distance'],
        'filters': {
            'age': 25,
            'distance': 5
        }
    }

    # After calling
    data_dict = {
        'fields': [],
        'filters': {}
    }
```

In that case, the validation succeeds and we can keep going. If there's still
any element left in the data_dict, that means that no extension understands it,
and we'll throw a ValidationError.
[#1725] Create proper plugin for testing

Instead of loading the plugin in a hackish way, we create a proper plugin and
load it the same way any other plugins is loaded.
[#1725] Move db._get_list to datastore_helpers.get_list

This method was already being used by action.py, and we'll need it soon enough
in other parts of the code, so we'd better make it public.
[#1725] Refactor DataStore's WHERE code to the DataStore plugin

The intent is for us to use the same extension points as third-party plugins,
so we can test that they work and that they're extensible enough.
[#1725] Adds search_data() extension point and change DataStore to use it

In a high level, extensions that implement this method are expected to add what
they want into a query_dict dictionary, defined as:

```
{
    'select': [],    # list
    'ts_query': '',  # string
    'sort': [],      # list
    'limit': 100,    # int
    'offset': 0      # int
}
```

This dictionary will be passed to each extension, and they can add or remove
attributes to it. Because of this, the order the extensions are loaded in the
.ini file matter.

At this point, the validations defined in validate_query() have already run.
[#1725] Fix PEP8 errors
[#1725] Remove useless code

This was moved to the Datastore plugin, so there's no need to be here anymore.
[#1725] Add test to guarantee that the filters received are in a dict
[#1725] Add tests asserting that the IDataStore.where() works for delete

It should be used both on datastore_create and datastore_delete.
[#1725] Add delete_data() extension point and remove where()

@amercader and I agreed that, even though in most cases both select_data() and
delete_data() would create the WHERE clauses with the same code, it's easier to
understand the WHERE being created inside each one of those, not on a separate
where() extension point.