Send the X-Content-Type-Options: nosniff header when serving attachments and resources

XWiki never sends the X-Content-Type-Options: nosniff HTTP response header, on any response, and neither do the servlet container configurations shipped with the distributions (Jetty, Debian packages). In particular it is missing from the responses that serve stored files:

• attachments served by the download action,
• resources and attachments served by the skin action,
• attachments served by the REST API,
• files served from attachments by the VFS resource handler.

These responses already declare what they contain: the Content-Type comes from the attachment's stored media type, and whether the file is displayed inline or downloaded (Content-Disposition) is decided from that same type and the attachment.download.whitelist, attachment.download.blacklist and attachment.download.forceDownload properties of xwiki.properties. Without nosniff, though, browsers are allowed to second-guess a declared type from the content ("MIME sniffing"). Sending it makes them honor the type XWiki declares, so what the administrator configured is what applies. It is also a standard hardening header that security scanners and hardening guides (e.g. the OWASP Secure Headers Project) check for; today administrators can only add it themselves, in a reverse proxy or in the servlet container.

Proposal

• Send X-Content-Type-Options: nosniff on the responses serving attachments and resources. The four places above already share XWikiAttachmentSecurityManager to compute their Content-Disposition header, which makes it a natural single place to add it.
• Alternatively, send it on every response, e.g. with the existing SetHTTPHeaderFilter declared in web.xml. Note that with nosniff browsers refuse to execute a script or apply a style sheet served with a type other than a JavaScript or CSS one, so the types of all scripts and style sheets (skin files, Skin Extensions, webjars, ...) must be correct first.

Noticed while working on XWIKI-25319.