Support parameter casting in composite schemas

[p1c2u]

Limitations

Greedy Casting in oneOf / anyOf:

The logic returns on the first successful cast:

   for subschema in self.schema / "oneOf":
       try:
           return self.schema_caster.evolve(subschema).cast(value)

The Edge Case: If you have oneOf: [{type: "string"}, {type: "integer"}] and the input is "123".

• If {type: "string"} is evaluated first, AnyCaster returns the string "123".
• If {type: "integer"} is evaluated first, it returns the integer 123.

Because it's greedy, the final type depends heavily on the order of the list in the OpenAPI spec. Downstream JSONSchema validation might act differently depending on this outcome. However, without combining casting and validation into a single complex step (which would require a massive rewrite of openapi-core), this greedy approach is the industry-standard compromise.

Value Mutation in allOf:

   if "allOf" in self.schema:
       for subschema in self.schema / "allOf":
           try:
               value = self.schema_caster.evolve(subschema).cast(value)

The Edge Case: If Subschema A casts the string "1" to an int, Subschema B will receive the int 1 to cast. If Subschema B is a string-based constraint (e.g., maxLength), the string caster might safely ignore the int or stringify it, but mutating the variable sequentially means subsequent casters operate on transformed data rather than raw data. Again, since allOf implies intersection, refining the variable sequentially is usually logically sound, but it's a subtle side effect.

Fixes #698