Quadratic CPU consumption in postal-mime RFC 2047 header decoding

### Impact Decoding a header that holds a long run of joinable RFC 2047 base64 encoded words, such as `=?utf-8?B?QUJD?=` repeated tens of thousands of times in a `Subject`, `From`, `To`, a filename or a description, took time quadratic in the number of words. The join check ran a regex over the text joined so far for every word, which flattens the accumulated string each time. A single well formed message of about 1.6 MB blocked the event loop for one to twenty seconds depending on the host, and inline `message/rfc822` parts multiplied the cost, since each nested message carried its own header budget. Any application that parses untrusted mail with postal-mime 3.0.0 through 4.0.7, including the exported `decodeWords()` helper, is affected. There is no confidentiality or integrity impact. ### Patches Fixed in 4.0.8. The pad check now tracks the last appended word instead of testing the joined text, so decoding is linear in the header length. The same release also counts the parts and header bytes of inline `message/rfc822` sub-messages against the limits of the message as a whole, counts every header line for at least 64 bytes of `maxHeadersSize`, and adds a scaling test that measures every stage of the parser at two input sizes. ### Workarounds Lower `maxHeadersSize` from its 2 MiB default to bound the cost per message, or parse untrusted mail in a worker that can be terminated. ### Credits Reported by Felipe Fernández.