Parameter Value is folded although already continuation is used

**Describe the bug**
When using a long filename in a multipart message this filename should be separated with Continuations, see https://tools.ietf.org/html/rfc2231: 3. Parameter Value Continuations.
This is used, but also folding (see https://tools.ietf.org/html/rfc5322#section-3.2.2) is used on top of it. As the goal of the "Parameter Value Continuations" is to avoid white space problems, folding should not be used here.

**To Reproduce**
```java
Session session = Session.getInstance(System.getProperties());
MimeMessage message = new MimeMessage(session);

MimeMultipart multipart = new MimeMultipart("mixed");
MimeBodyPart bodyPart = new MimeBodyPart();
bodyPart.setFileName("This is an attachment with a really long name - I hope it works like intended.txt");
bodyPart.setText("body-part-1 " + Instant.now());

multipart.addBodyPart(bodyPart);

message.setContent(multipart);
message.saveChanges();

FileOutputStream outputStream = new FileOutputStream(new File("out.txt"));
message.writeTo(outputStream);
```

Result is:
```
Date: Tue, 14 Jan 2020 18:17:05 +0100 (CET)
Message-ID: <1347137144.1.1579022225328@DWKA-4GYQH5J>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_0_1880587981.1579022225230"

------=_Part_0_1880587981.1579022225230
Content-Type: text/plain; charset=us-ascii;
name*0="This is an attachment with a really long name - I hope it
wo"; name*1="rks like intended.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename*0="This is an attachment with a really long name - I hope
it wo"; filename*1="rks like intended.txt"

body-part-1 2020-01-14T17:17:05.242Z
------=_Part_0_1880587981.1579022225230--
```

**Expected behavior**
Result should be

```
Content-Type: text/plain; charset=us-ascii;
name*0="This is an attachment with a really long name - I hope it wo";
name*1="rks like intended.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename*0="This is an attachment with a really long name - I hope it wo";
filename*1="rks like intended.txt"
```

**Desktop (please complete the following information):**
- OS: Ubuntu
- Version 18.04.3 LTS

**Additional context**
Used Version Jakarta Mail 1.6.4

Start by running the Java reproduction using MimeMessage, MimeBodyPart, saveChanges(), and writeTo(), then compare the generated headers with the expected output and the linked RFC 2231 and RFC 5322 sections. Done means parameter continuations remain split as expected without additional folding inside their values.

Written by the indexing model from the issue text.