Split the media-handler files into one type per file

[jkmassel]

Follow-up from #621. The media files each hold several types, so the "server" files are doing far too much:

• ios/.../Media/MediaUploadServer.swift — ~795 lines: the server plus the ~275-line InternalMediaClient, UploadError, and UploadContext.
• android/.../gutenberg/MediaUploadServer.kt — ~758 lines: the response model, both protocols, both value types, the server, the exception, and the client.

Proposed split

One concern per file, kept in the same module/package — so no import-path or public-API change, purely organization:

File	Holds
MediaProcessor.{swift,kt}	MediaProcessor (+ the iOS default-impl extension) & its result type ProcessedProxyFile
MediaUploader.{swift,kt}	MediaUploader & its input type MediaUpload
MediaUploadResponse.{swift,kt}	MediaUploadResponse (the shared internal relay model)
InternalMediaClient.{swift,kt}	InternalMediaClient (the concrete configured-site REST client)
MediaUploadServer.{swift,kt}	the server + its privates (UploadContext; UploadError / MediaUploadException)

iOS's MediaHandlers.swift dissolves into the first three.

Grouping rationale: each value type sits with the protocol it serves (ProcessedProxyFile → processor, MediaUpload → uploader); MediaUploadResponse gets a neutral home since the client and the server both use it; server-privates stay with the server.

Notes

• Mechanical and low-risk — no logic changes, stays within the existing module/package, so hosts see no API change. Builds + the existing media test suites are the check.
• Keep the media types in the org.wordpress.gutenberg package on Android; a media subpackage would be a public-API break for hosts.