Better support for layout features in the segmenter.

@skef

To start here's what the current state of layout feature handling in the segmenter is:

(this description is using terminology from: https://github.com/w3c/ift-encoder/blob/main/docs/segmenter.md#concepts)

• IFT Spec Default Features: we load this list from the spec and these are all included in the init font.
• Segmenter config proto: full support for customizing how features are allocated to input segments and merge groups. Additionally supports automatic handling of assignments.
• Auto Config: default behaviour is to place each non-default feature into it's own segment and all segments end up in the "Ungrouped" merge group. This group utilizes Heuristic merging.
• Dependency graph/condition analysis: features are fully supported here. The generated glyph patch loading conditions will correctly include feature segments.
• Frequency data: unsupported, currently only codepoint frequency data is available and supported. We currently hardcode a probability of 0.1% for each feature tag (ref: https://github.com/w3c/ift-encoder/blob/main/ift/freq/unicode_frequencies.h#L48).

Some special casing has been implemented around feature tags:

• Heuristic merging of feature only segments is disabled since the results of heuristic merging + features are often sub-optimal. (https://github.com/w3c/ift-encoder/blob/main/ift/encoder/merger.cc#L707)
• Merges (either cost or heuristic) that would mix a feature and codepoint into a single segment are also disabled (https://github.com/w3c/ift-encoder/blob/main/ift/encoder/candidate_merge.cc#L944)

What this means in practice for typical auto config usage:

• Each feature starts in it's own segment.
• All feature segments are processed using heuristic merging in the "Ungrouped" merge group, which does not perform merges on feature segments.
• For codepoints and glyphs that have interactions with feature segments. Cost based merging assessment will include the contribution of interactions with features. However, the cost deltas arising from this do rely on the hardcoded feature tag probability so accuracy of the deltas is questionable.
• Since feature segments are not merged, final segmentation will have each feature it's it's own segment. A segment is the smallest unit that per glyph conditions are constructed from.
• Patch to patch merging: is restricted to only consider cases that do not cross the boundaries of a merge group. So patches with features in their conditions are not eligible.

If auto config is not used and instead a hand written segmenter config is provided, then features can be pre-grouped into segments and merge groups as desired. Participation in cost merging can be enabled this way if desired (by having the feature segment in a cost based merge group).

Possible Improvements

The largest immediate improvement we can make is to allow features to better interaction with cost merging:

1. Create a frequency data source for features, of particular interest would be feature occurrence within the context of each script (including bigrams with other codepoints). Having this data may allow the feature codepoint mixing restriction to be lifted.
2. In the auto config setup allow features to participate in cost based merging. Currently feature segments end up in the heuristic ungrouped merge group. Auto config should determine which codepoints particular features interact with and place those feature segments into the appropriate script merge group. This will allow feature segments to be eligible for segment to segment and patch to patch merging based on cost (ideally with 1 in place to make the cost calculations more accurate).
3. We will likely want to special case how minimum group size enforcement works with respect to feature segments.

We likely also want to consider more special casing/handling of features (particularily aalt likely needs special handling). https://github.com/w3c/ift-encoder/blob/main/docs/experimental/some_hypo_seg_principles.md#glyph-keyed-feature-patch-principles is a good starting point for some ideas.

Start with docs/segmenter.md and the current feature handling described in this issue. Then inspect ift/encoder/merger.cc, ift/encoder/candidate_merge.cc, and ift/freq/unicode_frequencies.h, followed by the experimental feature principles document. A complete change would need a narrowly defined improvement among frequency data, auto-config merge groups, minimum group sizing, or special handling for features, with tests demonstrating the intended segmentation behavior.