Extraneous whitespace in Content-Disposition filename parameter causes parse error

I sporadically had trouble extracting attachments from some received mails, which when checked do work in GMail. After analysis, I traced it down to extraneous whitespace in the Content-Disposition header of the attachment part.

Specifically, the following headers:

```
--boundarystring
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename = "file.pdf"

[base64 data]
```
fail with the follow parse error:
```
#
```

removing the extraneous whitespace around the `=` character:
```
--boundarystring
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="file.pdf"

[base64 data]
```
works as expected.

Both cases work as expected in GMail.

I've checked RFC 2183 and RFC 822, and it is not entirely clear to me whether this white-space is legal ([RFC 822 section 3.1.4](https://tools.ietf.org/html/rfc822#section-3.1.4) does say "free insertion of linear-white-space (which permits folding by inclusion of CRLFs) is allowed between lexical tokens." but I do not know if that applies here).

Regardless of standards conformance, there is probably no downside to being slightly more lenient here and allow the spaces.

Probably somewhat related: #200

Start by tracing the Mail::ContentDispositionElement parser implicated in the error and reproduce the two Content-Disposition headers from the issue. Done means the parser accepts optional whitespace around the equals sign and a regression test covers the previously failing filename parameter.

Written by the indexing model from the issue text.