fix: emit anyOf instead of oneOf in complex enum schemas

[maxconway]

Oneof isn 't compatible with Openai, anyOf is.

I've also included a test to demonstrate the problem.

I think semantically anyOf makes at least as much sense as OneOf, so I'm guessing this is a deliberate choice by openai, rather than a bug

[clifton]

[edit: llm wrote the following]

Robustness review update after running locally with provider keys enabled:

I validated the oneOf -> anyOf behavior against both schema-level and live integration paths. The provider-facing tests for Gemini and OpenAI pass locally with real credentials, so the primary behavior change is working.

I also found two coverage/compatibility gaps worth folding into this PR:

1. rstructor_derive/tests/enum_with_data_tests.rs still asserted oneOf, so derive-package coverage was stale after this change.
2. Gemini adjacency normalization in src/backend/utils.rs was only applied on oneOf; after this PR emits anyOf, adjacently tagged enum normalization could be skipped in that path.

I prepared a follow-up commit that addresses both:

• 86b1ffa (fix: normalize anyOf adjacently tagged enums for Gemini)

What it adds:

• normalizes adjacently tagged variants for both anyOf and oneOf
• extends adjacency extraction to recognize anyOf
• adds focused unit coverage for anyOf adjacency handling
• updates stale derive test assertions to anyOf

Local validation for that follow-up commit:

• cargo clippy --workspace --all-targets --all-features
• cargo test -p rstructor_derive --test enum_with_data_tests
• cargo test --lib backend::utils::tests
• cargo test --test nested_enum_tests --test serde_rename_tests
• cargo test --test complex_enum_integration_tests
• cargo test --test openai_enum_anyof_test

If useful, I can port this commit directly onto the PR branch.

[clifton]

tests all pass locally. thank you for the contribution!