perf: optimize factorial function performance

[getChan]

Which issue does this PR close?

• Closes #.

Rationale for this change

benchmark

factorial_array         time:   [778.63 ns 783.03 ns 787.52 ns]
                        change: [−90.314% −90.211% −90.055%] (p = 0.00 < 0.05)
                        Performance has improved.

factorial_scalar        time:   [317.32 ns 319.36 ns 321.41 ns]
                        change: [−28.219% −27.508% −26.683%] (p = 0.00 < 0.05)
                        Performance has improved.

What changes are included in this PR?

1. factorial implementation from using loop to looking up precomputed values.
2. using the try_unary kernel function on PrimitiveArray. (However, since this isn’t unary function, it does not get vectorized execution)

and add benchmark

Are these changes tested?

Yes.

Are there any user-facing changes?

No.

[comphead]

it should prob to be exec_err!

[getChan]

thanks! applied it

[comphead]

Thanks @getChan it makes sense as long as input is i64, for bigger input datatypes it would be needed to expand the lookup table, for example duckdb supports larger factorial and converts it to i128

D select factorial(33);
┌───────────────────────────────────────┐
│             factorial(33)             │
│                int128                 │
├───────────────────────────────────────┤
│ 8683317618811886495518194401280000000 │
└───────────────────────────────────────┘

[Jefffrey]

This is very nice 🚀

[comphead]

@getChan please resolve conflicts

[Jefffrey]

Thanks @getChan & @comphead