feat(query): add chain function support

[sundy-li]

I hereby agree to the terms of the CLA available at: https://databend.rs/dev/policies/cla/

Summary

Summary about this PR

Changes:

1. Introduce DotAccess in expr element which will handle the column_ref, chain_function, map_access in pos travel.

Also fix the bug of:

select  1 + {'k1': 4}.k1;

2. chain function support (in dialect Experimental)

This pr adds chain function support which will take the receiver into the first arg of normal function, examples:

🐳 :) select (3).add(4), 3 + {'k1': 4 }.k1, (3).add({'k1': 4 }.k1),  '3'.plus(4);
┌────────────────────────────────────────────────────────────────────┐
│ add(3, 4) │ (3 + {'k1':4}:k1) │ add(3, {'k1':4}:k1) │ plus('3', 4) │
│   UInt8   │       UInt8       │        UInt8        │     UInt8    │
├───────────┼───────────────────┼─────────────────────┼──────────────┤
│         7 │                 7 │                   7 │            7 │
└────────────────────────────────────────────────────────────────────┘


🐳 :) select 'openai'.upper();
┌─────────────────┐
│ upper('openai') │
│      String     │
├─────────────────┤
│ OPENAI          │
└─────────────────┘

🐳 :) with t(f) as (select '11|open|22|ai|33|is nothing without sam'.split('|')
        .array_filter(x -> try_cast(x as int) is not null ).array_apply(x -> x::int ).array_apply(x -> x::int64 ))
        select f.array_reduce('sum'), f.array_reduce('max'), f.array_reduce('min')  from t;
┌──────────────────────────────────────────────────────────────────────────┐
│ array_reduce(f, 'sum') │ array_reduce(f, 'max') │ array_reduce(f, 'min') │
│     Nullable(Int64)    │     Nullable(Int64)    │     Nullable(Int64)    │
├────────────────────────┼────────────────────────┼────────────────────────┤
│                     66 │                     33 │                     11 │
└──────────────────────────────────────────────────────────────────────────┘

• Closes #issue

---

This change is 

[andylokandy]

Should we add an experimental feature gate for chain function?

[sundy-li]

Should we add an experimental feature gate for chain function?

Looks like it's syntactic sugar, it has no impact on existing usage, so maybe no need to add the setting.

Settings can't control AST's behavior, this is already rewritten into a normal function after parser.

[andylokandy]

A feature gate makes room for future syntax breaking changes. Otherwise, the syntax is sealed now. The syntax behavior can by specified by the Dialect passed to the parser.