Request for support for complex/null operators
Hmm...while I can see the benefit of allowing operations to map to callables, I do not have plans to add that currently. You can always subclass `QueryCompiler` and provide your own implementation for `_parse_expression` that does the right thing.

As requested in the online documentation, I am proposing a feature change for peewee, as described below.

While looking at subclassing peewee.Database for a project, I quickly realized that some operations that work on PostgreSQL or SQLite have no _direct_ analogy on some platforms I'm looking to use it with. Usually, that has been because peewee expects comparison clauses to always be expressed using _in-fix_ semantics (eg _&lt;left_operand&gt; &lt;operator&gt; &lt;right_operand&gt;_), which isn't always possible.

Similarly, if a given operation cannot be supported at all (eg regex matching), there is no way to _forbid_ use of the corresponding peewee expressions. I could let those operations fail in the database (leading to troubleshooting based on DBMS error text), but that's nowhere near as useful as would be an exception raised by peewee containing a clearly-worded message.

To address these, I want to modify `QueryCompiler()._parse_expression()` so that _overridden_ operators don't necessarily have to be strings, but can also be a callable or `None`. Use of `None` would indicate an unsupported operator whose use raises an exception, while a callable would be expected to assemble and return whatever complex clause is needed to get the job done.

Here is an example that would become possible with the proposed change:

``` python
class MyCustomDB(peewee.Database):
    op_overrides = {
        peewee.OP.REGEXP: None,  # Raise ValueError if somebody tries this
        peewee.OP.LIKE:   lambda l, r: '%s LIKE %s COLLATE Latin1_General_BIN' % (l, r),
        peewee.OP.ILIKE:  'LIKE',
        peewee.OP.XOR:    lambda l, r: '((%s AND NOT %s) OR (NOT %s AND %s))' % (l, r, l, r),
    }
    # ...
```

Thoughts?
