Multiple ways to express `like` / `ilike` / `not like` / `not ilike`

[alamb]

Describe the bug
There are two ways to express pattern matching in datafusion Exprs.

Expr::Like(Like)
..

https://github.com/apache/arrow-datafusion/blob/3abbffb5c83395e8e6e68e5529835e72e7769d0d/datafusion/expr/src/operator.rs#L55-L61

As well as

BinaryExpr {
 left: ..
 op: Operator::Like,
 right: ..
}

This causes issues such as the simplification in #4646 only affects the BinaryExpr form, not the Expr::Like form

The Expr::Like form is more full featured (can have pattern substitution)

Expected behavior
I would like to have a single way to represent these operators. I believe it should be Expr::Like, Expr::ILike, Expr::NotLike and Expr::NotILike as they have more features.

Thus, I would like to remove Operator::Like, Operator::ILike, Operator::NotLike, and Operator::NotILike and update all tests / code to use Expr::Like

Additional context
Noticed while reviewing #4646 from @crepererum

I am marking this as "good first issue" as it is mostly a software engineering exercise and would be guided by the compiler -- it would be a good exercise to get familiar with DataFusion's codebase

[crepererum]

Note that the expression variant supports specifying escape characters (as the SQL does) but the binary expression doesn't support options / a third input (its binary after all) and the arrow kernels don't support escape characters at the moment. Currently the physical plan construction fails if an escape character is specified and this behavior should be carried over (if the feature gap in the arrow kernels isn't addressed beforehand).