ISO-8859-8-i should be mapped to ISO-8859-8 (Hebrew, see caveats)

The ISO-8859-8-i charset (Hebrew with logical ordering) should be mapped to ISO-8859-8, as it can currently not be decoded with `MimeUtility.decodeText()`, even though it is the exact same per-character encoding as ISO-8859-8, just the implied direction is reversed from visual order to logical order.

Java strings are usually stored in logical order, and the resulting Java strings can be correctly displayed by many applications (browsers, editors, Eclipse editor+console, etc), even when they contain right-to-left (RTL) pieces of text. Therefore, it is not necessary to reverse ISO-8859-8-i strings before decoding. If a left-to-right character-wise "visual" representation is needed, then the string would need to be reversed.

Note: This probably also means that currently, ISO-8859-8 ("visual ordering") encoded strings are displayed wrongly in RTL-aware applications that directly display the strings that MimeUtility.decodeText() outputs.

EDIT: It would be great to get some feedback from Hebrew-speaking developers, as I don’t speak it.

Some links:
- https://www.ietf.org/rfc/rfc1555.txt (Hebrew Character Encoding for Internet Messages)
- https://tools.ietf.org/html/rfc1556 (Handling of Bi-directional Texts in MIME)
- https://docs.oracle.com/javase/tutorial/2d/text/textlayoutbidirectionaltext.html
- https://www.w3.org/International/questions/qa-visual-vs-logical
- https://en.wikipedia.org/wiki/ISO/IEC_8859-8

The entry point named by the issue is MimeUtility.decodeText(); begin by tracing how charset names are resolved there and reviewing RFC 1555, RFC 1556, and the linked bidirectional-text references. Done means the ISO-8859-8-i case is handled consistently with the stated encoding behavior and the visual-versus-logical ordering caveat is explicitly resolved.

Written by the indexing model from the issue text.