Implement RTL and BIDI text support

[dhardy]

This adds support for:

• shaping right-to-left text (doesn't actually require re-ordering since we just read the text backwards),
• line-wrapping right-to-left text (harder than expected),
• splitting runs when the BIDI embedding level changes,
• and glyph-mirroring.

As such, it can now display simple bidirectional text.

Also, text navigation will need many fixes. That will be another PR.

[dhardy]

The promised screenshot:

Sample text is taken from r12a. There are some notable issues here, which are left for now:

• We consider all positions where the bidi-level changes to be valid line-wrap positions, hence how this text wraps just after an opening '('; fixing this is probably possible by adding a "do not break" flag to the Run struct, but would require further changes to how unsplittable-run-length is calculated in the line-wrapping algorithm.
• '10-12' should read '12-10' since the numbers are LTR, but the sequence is RTL. Run-reordering should have fixed this except that unicode-bidi reports the whole as having a single run-level: Level(2), text[243..248]: '10-12', breaks=[]. Results are identical with the unic-bidi fork. This may be due to https://github.com/servo/unicode-bidi/issues/8 .
• The diacritics above the last line of Arabic should be visually distinct. I presume HarfBuzz should be responsible for this.
• We do not strictly implement line re-ordering as per the specification: we do not reset embedding levels as per L1 since we are not dealing with chars but runs and cannot at this point easily sub-divide those (see below). So far I haven't noticed issues caused by this.
• Line spacing should possibly be greater; currently we use one line-height for all scripts.
• Text navigation needs lots of fixes. As said above, this will be another PR.
• Edit-markers should appear on the right of RTL glyphs; finding this position requires the right-side-bearing which isn't reported by the font libraries currently in use.

Frankly, I've already put more work into supporting BIDI than I have justification for, so likely won't work further on this (besides navigation). The rationale was to test that the crate's architecture was compatible with BIDI processing, to which the answer seems to be just about. From reading Unicode TR#9, it almost seems like shaping must happen twice: first to measure the widths of unsplittable text segments, and second to draw glyphs after rearranging characters, however initial shaping on RTL text must already use the correct glyph order and any differences between initial and final shaping could generate incorrect line length, so practically speaking this would appear unnecessary.

[dhardy]

To conclude the above paragraph: this implementation uses a single shaping pass. There may be limitations, but is seems good enough (at least for now).