At least on Windows, some static variables are lazily initialized
during `mail_open()` and `mail_lsub()`, which are reported as memory
leaks.  We suppress these false positives.

Closes GH-6326.

* PHP-7.3:
  Fix #80226: imap_sort() leaks sortpgm memory

We need to free what we have allocated.

Closes GH-6327.

The message patterns can be pretty complex, so reporting a generic
U_PARSE_ERROR without any additional information makes it needlessly
hard to fix erroneous patterns.

This commit makes use of the additional UParseError* parameter to
umsg_open to retrieve more details about the parse error to report that
to the user via intl_get_error_message()

Additional improve error reporting from the IntlMessage constructor.
Previously, all possible failures when calling IntlMessage::__construct()
would be masked away with a generic "Constructor failed" message.
This would include invalid patterns.

This commit makes sure that the underlying error that caused the
constructor failure is reported as part of the IntlException error
message.

Closes GH-6325.

* PHP-7.3:
  Fix #80216: imap_mail_compose() does not validate types/encodings

We need to check whether the given `type`s and `encoding`s are within
bounds to avoid segfaults and out-of-bound reads.

Closes GH-6323.

* PHP-7.3:
  Fix #80223: imap_mail_compose() leaks envelope on malformed bodies

We have to clean up even on failure.

Closes GH-6322.

* PHP-7.3:
  Fix #80220: imap_mail_compose() may leak memory

Unless `topbod` is of `TYPEMULTIPART`, `mail_free_body()` does not free
the `nested.part`; while we could do this ourselves, instead we just
ignore additional bodies in this case, i.e. we don't attach them in the
first place.

Closes GH-6321.