Unify Handling of allOf/anyOf and oneOf in Diff logic

Current Behavior:

The diffing mechanism currently handles allOf/anyOf and oneOf differently within composed schemas:

1. allOf/anyOf: These schemas are recursively resolved and their properties are merged into the parent schema before the main diffing occurs. This happens in SchemaDiff#resolveComposedSchema, where properties from allOf/anyOf subschemas are added to the parent using SchemaDiff#addSchema. The original allOf/anyOf structure is effectively flattened.

2. oneOf: These schemas are not merged beforehand. Instead, the ComposedSchemaDiffResult#diff method performs a structural comparison of the oneOf lists between the old and new schemas. It identifies added, removed, or changed oneOf options, storing the results in a ChangedOneOfSchema object which is then attached to the ChangedSchema.

Suggested Behavior:

This difference in processing leads to an inconsistency. While the merging for allOf/anyOf simplifies property comparison later, it loses the structural information about changes within the allOf/anyOf lists. Conversely, oneOf retains this structural information because it's crucial for understanding changes in available options.

Consider unifying the approach. Perhaps allOf/anyOf could also be compared structurally, similar to oneOf, to provide a more consistent and potentially more informative diff result regarding the composition itself, rather than just the flattened outcome. This would allow tracking additions, removals, or modifications within allOf/anyOf lists directly.

Start with SchemaDiff#resolveComposedSchema and SchemaDiff#addSchema to understand how allOf/anyOf are flattened, then read ComposedSchemaDiffResult#diff and ChangedOneOfSchema for the existing oneOf comparison. Define how structural additions, removals, and modifications in allOf/anyOf should appear alongside flattened property changes; done means the diff reports composition changes consistently without losing relevant details.