Renamed ignore_like to unlike

[alexksikes]

This changes the parameter name ignore_like to the more user friendly name
unlike. This later feature generates a query from the terms in A but not
from the terms in B. This translates to a result set which is like A but
unlike B. We could have further negatively boosted any documents that have
some B, but these documents already do not receive any contribution from
having B, and would therefore negatively compete with documents having A.

[jpountz]

I'm a bit uncomfortable with this renaming given that ignore_like better describes the current behaviour, given that we just ignore the negative terms? unlike would feel to me like we give negative boosts to documents that contain the negative terms, which is not what we do?

[alexksikes]

So suppose we have like A but unlike B type of query. Under the hood we form a query made of the terms in A - B. So we are interested about the documents (vectors) near the vector A - B, which corresponds to a result set in which the user gets documents which are like A but unlike B. Sure some documents could have some terms in B but they would not contribute to the score of the document, only the terms in A - B contribute to such a score. Also if we wanted to further negatively boost the terms in B, the user could always use boosting queries. I think that unlike reads much better than ignore_like from user perspective.

[clintongormley]

It's tricky. I kinda read ignore_like as a stronger promise: don't return anything like FOO. unlike feels a bit weaker, so I think I'd stick with unlike

[jpountz]

OK, let's merge then!