ORC-1884: [C++] Add a maybe() API to the SearchArgumentBuilder

[luffy-zh]

What changes were proposed in this pull request?

Add a maybe() API to the SearchArgumentBuilder to allow the insertion of an expression tree that is currently unsupported.

Why are the changes needed?

To enhance the SearchArgumentBuilder API with a new method called maybe(), we can create a SearchArgument tree for scenarios that may not be adequately addressed by existing methods.

How was this patch tested?

Uts in TestSearchArgument.cc can cover this patch.

Was this patch authored or co-authored using generative AI tooling?

NO

[dongjoon-hyun]

Thank you for making a PR.

For the following claims, It seems unclear to me because there is no actual test case.

Allow the insertion of an expression tree that is currently unsupported.

I'd like to recommend the following.

• Revert the change on the existing test case.
• Add a new test case which shows the claim, "the insertion of an expression tree that is currently unsupported".

In general, your new test case should verify your code contribution. For example, the new test case should fail without your patch. AFAIK, this PR only adds .maybe() to the existing successful test cases. So, it's improper to validate this PR's contribution.

[ffacs]

Is maybe() a shortcut of literal(TruthValue::YES_NO_NULL)?

[luffy-zh]

Is maybe() a shortcut of literal(TruthValue::YES_NO_NULL)?
Yes, maybe() can be considered a shortcut for literal(TruthValue::YES_NO_NULL). It provides a more concise way to express uncertainty or ambiguity in truth values.

[ffacs]

LGTM

Stale.

[dongjoon-hyun]

Hi, Yuanping (@ffacs), if you think it's okay, you can merge this. Feel free to merge this PR because I removed my review here. 😄

[williamhyun]

+1 LGTM

[dongjoon-hyun]

Let me merge this.

[dongjoon-hyun]

Thank you, @luffy-zh and all.