This is getting a bit in the weeds here, but I think it's worth talking about a little bit.  The FE 1.0 and 1.1 specs say that `PropertyIsLike` takes a `PropertyName` and a `Literal`.  This sort of follows given the element name, but it is oddly restrictive.  For example, `PropertyIsEqualTo` (and all the other `BinaryComparisonOpType`) take two `expression` arguments.  This makes more sense.  In Filter Encoding 2.0, they bring more consistency with `PropertyIsLike` taking two `expression` arguments.

In ol3 terms, we allow people to create an expression like this: `foo == "bar"`.  In this case, the two expressions are an identifier and a literal, but they could have also been two identifiers, or an identifier and a call expression.  This jives with FE (1 and 2) allowing `PropertyIsEqualTo` to be a comparison between any two other expressions (despite the name making it sound like the first one has to be a `PropertyName`).

It makes more sense to me to also allow these string comparison functions to be called with any two expressions - and we assume those expressions are going to evaluate to strings (error handling can discussed separately).  So we would allow someone to do this: `like(foo, "bar*")`.  In this case, the lib function is going to get called with whatever `foo` (i.e. `feature.get('foo')` evaluates to and `"bar*"`.

Then, if we're strictly following FE 1.x, when we serialize a call expression to the `like` function, we can only serialize properly if the first argument is `ol.expression.Identifier` (as it is in the example above).  Serializing FE 2.x, we could seralize even if the first argument is a more complex expression (e.g. `like(foo + bar, "baz")`).  

Anyway, I don't think we should be slaves to OGC specs here, but since they've corrected themselves, there is even less reason to have these functions (`like`, `ieq`, `ineq`) be restricted to taking string attribute names as the first argument.

To be more specific about what I think should change, I'll add one comment to the docs above and other comments below.