Allow using a named schema both in JSON and mutlipart payloads

### Description

The current Twitter OpenAPI doc produces non-compiling Swift code: https://api.twitter.com/2/openapi.json

Error is: `Types.swift:22261:84: 'AddOrDeleteRulesRequest' is not a member type of enum 'Generated.Components.Schemas'`

The root cause is a limitation in the current multipart implementation in the generator (multipart details: https://swiftpackageindex.com/apple/swift-openapi-generator/1.7.0/documentation/swift-openapi-generator/soar-0009).

Today, the generator assumes that a schema is only ever used _either_ as a JSON payload (and generates it as a Codable type) _or_ as a multipart body, where the top level properties describe the individual parts (in this case the type isn't Codable, can't be because the parts might be binary payloads).

This comes through in the `isMultipartContent` boolean value in https://github.com/apple/swift-openapi-generator/blob/84b693f9d0559dc488e691edb4837bafbce2aaea/Sources/_OpenAPIGeneratorCore/Translator/CommonTranslations/translateSchema.swift#L71

Now, this limitation is in place because we assumed that multipart parts are often binary data, and thus aren't compatible with being encoded in JSON.

However, this specific Twitter example does something different: they use the same schema for both JSON and multipart, and the schema itself only uses JSON-compatible types, and never binary data. So _technically_ there isn't a good reason the generator should fail here, but it does, because we didn't expect this to be a common occurrence.

### Reproduction

An OpenAPI doc that has a single reusable schema and uses it from two request bodies, one multipart, one JSON.

### Package version(s)

swift-openapi-generator 1.7.0

### Expected behavior

Either:
1. Relax the checking and allow the reuse as long as none of the top level properties of the schema is a binary payload.
2. Catch this case during code generation and fail with a descriptive error saying that this isn't supported.

However, today the generation succeeds, and the building the code fails. We want to avoid that whenever possible.

### Environment

Swift 6.0.3

### Additional information

_No response_

Start in Sources/_OpenAPIGeneratorCore/Translator/CommonTranslations/translateSchema.swift at the isMultipartContent logic. Reproduce the case with one reusable schema referenced by JSON and multipart request bodies, using the Twitter OpenAPI document or the described minimal document. Done means generation either supports the shared schema without producing non-compiling Swift, or rejects it with a descriptive error.

Written by the indexing model from the issue text.