Consider this query: `select * from tab where date = '1970-01-01'`

Without these new functions QuestDB resorts to picking the overloaded
equal function which accepts 2 longs. Why?
1. There is no exact match for eq(Date, Date) - such function does not exist at all!
2. The date column is `DateColumn` and the Date type can be casted to Long.
   See the overloading priority: /* 7  DATE      */, {DATE, TIMESTAMP, LONG}
3. The second parameter is `StrConstant` and String can be also casted to Long.
   Again, the overloading priority:  /* 11 STRING    */, {STRING, CHAR, DOUBLE, LONG, INT, FLOAT, SHORT, BYTE}
4. Hence, the function parser picks eq(Long, Long).

But then the `StrFunction.getLong()` fails to parse '1970-01-01' as a long.
It expects a simple number. It does not know it's supposed to treat the argument as a Date.

The same query works if you change the column type from Date to Timestamp.
Why? Timestamp does not rely on casting - it implements Timestamp-specific
functions where necessary. So I copied this for Date.

treat such timestamps as UTC

…tterns

also: more tests for Date casting

…3864)

…3864)

…n tables (#3857)

…3864)

…3864)

for =() only. for now.

This reverts commit 08a6963.