Clarify the "invalid_filetype" upload error message

[thorr19]

The invalid_filetype error string in wp_default_scripts()

(src/wp-includes/script-loader.php) currently reads:

"This file cannot be processed by the web server."

This implies a server fault when the actual cause is that
WordPress does not accept the file's MIME type. The wording
is also inconsistent with neighboring strings in the same
$uploader_l10n array, which all explain the cause and
suggest an action:

• zero_byte_file: "This file is empty. Please try another."
• not_an_image: "This file is not an image. Please try another."

Proposed change:

"This file type is not supported. Please try another."

This pattern-matches the surrounding strings, removes the
misleading "web server" framing, and tells the user what to
do next.

See also: #61361, which addressed the analogous image-specific
wording (noneditable_image) for the same reason. The
invalid_filetype message was not touched in that ticket but
suffers the same vagueness.

A PR with this change is in flight on GitHub and will be linked
once opened.

## Trac ticket

https://core.trac.wordpress.org/ticket/65374

## Summary

The invalid_filetype error string in wp_default_scripts() (src/wp-includes/script-loader.php) currently reads:

This file cannot be processed by the web server.

This implies a server fault when the actual cause is that WordPress does not accept the file's MIME type. The wording is also inconsistent with neighboring strings in the same $uploader_l10n array, which all explain the cause and suggest an action:

• zero_byte_file: _"This file is empty. Please try another."_
• not_an_image: _"This file is not an image. Please try another."_

Proposed change:

This file type is not supported. Please try another.

This pattern-matches the surrounding strings, removes the misleading "web server" framing, and tells the user what to do next.

## Related

See also Trac #61361, which made the analogous wording improvement to the image-specific noneditable_image message for the same reason. The invalid_filetype string was not touched in that ticket but suffers the same vagueness.

Tested using WordPress Playground, fix works as expected!