Bug: email parser mishandles old-style boundaries

The code that parses boundary strings strips <>. This breaks parsing of some messages, for example the unit test corpus file tomcat-ancient-boundary.mbox which has the following boundary:

Content-Type: multipart/mixed; boundary="<<001-3e1dcd5a-119e>>"

Once parsed, the boundary becomes "<001-3e1dcd5a-119e>" which does not match.

There are two bugs for this:
https://bugs.python.org/issue28945
https://bugs.python.org/issue29020
but unfortunately no fix in sight.

It's possible to monkey-patch the library by providing a replacement copy of the method email.utils.collapse_rfc2231_value.

It might make sense to add this as an option (at least initially) for the importer so that missing messages could be imported.

Attached is some test code to demonstrate the fix.

[parse_email.py.zip](https://github.com/apache/incubator-ponymail/files/5087155/parse_email.py.zip)

[Copied from https://github.com/apache/incubator-ponymail/issues/519]

Start with the email.utils.collapse_rfc2231_value behavior described in the issue and reproduce the failure using the attached parse_email.py test code and unit corpus file tomcat-ancient-boundary.mbox. Trace how the boundary is handled by the importer, then verify that the old-style boundary remains matchable and that affected messages can be imported without being missed.

Written by the indexing model from the issue text.