[wip] Automatic label anchor

[karimnaaji]

Support for automatic anchoring fallbacks (based off #749).

Defined in the stylesheet as the following (series of fallback separated by commas):

text:
    anchor: right, bottom, left, top

For any labels with potential anchor fallbacks, when a collision happens a label would enter in the anchor_fallback state at frame n, they would enter within this state, the collision system will then try their new position at frame n+1, if no collision happens, they would then get to their visible state, otherwise they would keep trying the next fallbacks on the next frames until they have looped on all of them.

Anchor fallback and dynamic text realignment

• If no align: property is given, the fallback would automatically realign the text;
  • fallback anchor to right, automatic realignment to left
    
  • fallback anchor to bottom, automatic realignment to center
    
• If align: property is given, the preferred alignment would be assigned to every anchor fallback.

To implement realignment when anchor is being switched, the text quads are being drawn for each of the fallbacks (so quads would be correctly positioned for each of the fallbacks). Then a list of quad ranges associated with their alignment are being given to the text label so it can switch between the quad ranges at render time.

To improve determinism

When a label is colliding and fallbacks to the next anchor, it would stick to this anchor until a new collision happens (where it should fallback to the preferred anchor when space is again available):

TODO

• Update unit tests

[bcamper]

This is cool! For syntax, while it's in some ways a little less friendly, I'd prefer to use a YAML list to specify multiple anchors. While it's more verbose, it's more consistent with how we've handled single vs. multiple values for other parameters, and it's more explicit and only uses built-in YAML processing vs. being dependent on additional string parsing, e.g. both are valid:

Single value: anchor: top
Multiple values: anchor: [right, bottom, left, top]

[bcamper]

I'll make an issue for this for JS. Note that initially we may have to just stub this out, making it take the first specified anchor value and ignore the rest (but accept this syntax rather than failing to parse the feature, for scene file compatibility).

[karimnaaji]

Closing in favor of #842