feat(c++): add field validation options for cpp generator

[Pastoray]

Why?

FDL currently lacks a way to express validation constraints directly in the schema. Users must manually write validation logic in their application code, leading to duplication and boilerplate.

What does this PR do?

Parser: Adds recognition of validation options (gte, lte, gt, lt, eql, neq, min_len, max_len, pattern, uuid, email, min_items, max_items) as valid field options (silencing the "Unknown option" warning).

Semantic Validator: Adds _check_validation_options() and _check_field_options() to ensure validation options are used on appropriate field types:

• Numeric options (gte, lte, gt, lt, eql, neq): only on numeric primitive types
• String options (min_len, max_len, pattern, uuid, email): only on string fields
• Collection options (min_items, max_items): only on list/array/map fields

C++ Generator: Adds a generate_validator() method that emits a namespace Validator { ... } block containing per-message validation functions. For each field option, the generator emits the corresponding C++ check:

• gte: obj.field() >= value
• min_len: obj.field().size() >= value
• pattern: std::regex_match(obj.field(), std::regex(R"(...)"))
• ...

Unit Test: Adds test_cpp_validation_options() in test_generated_code.py verifying that the generated C++ contains the expected checks.

Related issues

• [Question] Does Apache Fory support field validation inside *.fdl? #3904

AI Contribution Checklist

• Substantial AI assistance was used in this PR: yes / no
• If yes, I included a completed AI Contribution Checklist in this PR description and the required AI Usage Disclosure.
• If yes, my PR description includes the required ai_review summary and screenshot evidence or equivalent persisted links of the final clean AI review results from both fresh reviewers described in AI_POLICY.md, the Fory-guided reviewer and the independent general reviewer, on the current PR diff or current HEAD after the latest code changes.

Does this PR introduce any user-facing change?

Yes, new validation options in FDL fields:

int64 id = 1 [gte = 1, lte = 1000000];
string username = 2 [min_len = 3, max_len = 20, pattern = "^[a-zA-Z0-9_]+$"];
string email = 3 [email = true];
string uuid = 4 [uuid = true];
list<string> tags = 5 [min_items = 1, max_items = 5];

• Does this PR introduce any public API change?
• Does this PR introduce any binary protocol compatibility change?