feat: add benchmark for tuple

[illusory0x0]

tuple version always fastest

Some(Benchmark Task [forall] Count = 10
----------------------------------------
Average Time: 0.00208108s/per test
Max Time Per Test: 0.0013789s/per test
Min Time Per Test: 0.0010893s/per test
----------------------------------------)
Some(Benchmark Task [curry] Count = 10
----------------------------------------
Average Time: 0.00117167s/per test
Max Time Per Test: 0.0012509s/per test
Min Time Per Test: 0.0011124s/per test
----------------------------------------)
Some(Benchmark Task [tuple] Count = 10
----------------------------------------
Average Time: 0.00095804s/per test
Max Time Per Test: 0.0010731s/per test
Min Time Per Test: 0.0009049s/per test

[peter-jerry-ye-code-review]

‼️ This code review is generated by a bot. Please verify the content before trusting it.

Here are three observations from the provided git diff output:

1. Potential Logical Error in prop_symmetry Function:
   The function prop_symmetry checks if x == y == (y == x). This logic is redundant because x == y is already equivalent to y == x due to the symmetric property of equality. The expression x == y == (y == x) could be simplified to just x == y. This redundancy might not cause a bug, but it could lead to confusion or unnecessary complexity.

2. Missing Error Handling in Benchmark Tasks:
   In the benchmark tasks (test "forall", test "curry", and test "tuple"), the try block catches all exceptions with _ => (), which silently ignores any errors. This could hide potential issues during testing or benchmarking. It might be better to log or handle specific exceptions to ensure that any problems are visible and can be addressed.

3. Inconsistent Naming in Benchmark Results:
   The benchmark results are printed using println(r["forall"]), println(r["curry"]), and println(r["tuple"]). While this works, it might be better to use a more descriptive or consistent naming convention for the keys in the r object. For example, using a prefix like "benchmark_forall" or "benchmark_tuple" could make it clearer that these are benchmark results, especially if r contains other types of data.

These observations are not critical bugs but could be improved for better code clarity and maintainability.