CXF-8922: Default form-data parts without Content-Type to text/plain

[coheigea]

Since 3.4.6 AttachmentDataSource reports "application/octet-stream" for
parts with no Content-Type header, so the JAX-RS Attachment no longer
falls back to text/plain. As a result simple form fields bound to
non-String types (e.g. @multipart Integer) found no MessageBodyReader
and were silently injected as null.

Per RFC 7578 section 4.4, a multipart/form-data part without a
Content-Type defaults to text/plain. AttachmentUtil.createAttachment now
applies that default to form-data parts that are not files (no
"filename" parameter); other parts keep defaulting to
application/octet-stream, and the "org.apache.cxf.attachment.content-type"
property still overrides the default.

[reta]

We probably could pass filename to getDefaultContentType (since we already exacted it::

Suggested change

	getDefaultContentType(cd));
	ct = MessageUtils.getContextualString(message, ATTACHMENT_CONTENT_TYPE,
	getDefaultContentType(cd, filename));

May be we could even push it to:

ContentDisposition cd = getContentDisposition(headers, "Content-Disposition");

...
ct = MessageUtils.getContextualString(message, ATTACHMENT_CONTENT_TYPE,
                                                  getDefaultContentType(cd));