Favor previous anchor only when still in the text-variable-anchor options

[asheemmamoowala]

Addresses #8397

The text-variable-anchor implementation favored the previous anchor placement for symbols, even if the previous anchor was no longer an option in the text-variable-anchor value (when changed by setStlye or setlayoutProperty)

The benchmarks are unaffected because they don't exercise the text-variable-anchor property codepath. They use streets-v10 style which predates this property.

This PR also needs to be ported to gl-native:

https://github.com/mapbox/mapbox-gl-native/blob/a0e2064f75a229a0bc369ce023e2eaaccb6af074/src/mbgl/text/placement.cpp#L198-L202

• briefly describe the changes in this PR
• write tests for all new functionality
• manually test the debug page
• tagged @mapbox/studio and/or @mapbox/maps-design if this PR includes style spec changes
• tagged @mapbox/gl-native if this PR includes shader changes or needs a native port

cc @mapbox/studio @mapbox/gl-native @vakila

[samanpwbb]

This change will make text-variable-anchor updates deterministic in many cases, but doesn't fully resolve the problem.

---

Here's an example sequence in Studio where this change will result in a highly deterministic label placement outcome:

0. ["top", "bottom"] // starting value
1. ["top"] // user deletes bottom
2. ["bottom"] // user adjusts top value to bottom
3. ["bottom", "center"] // user adds a new element (starting value is always center)
4. ["bottom", "top"] // users adjusts center value to top.

And their resulting style would pretty accurately reflect how the style will be rendered after a hard refresh.

Here's another sequence that would result in a less deterministic label placement outcome:

0. ["top", "bottom"]
1. ["top", "bottom", "center"] // user adds another element
2. ["top", "bottom", "top"] // user changes 3rd element's value to top
3. ["bottom", "top"] // user deletes the first stop

The property value is the same as in the first example, but the preference for "top" then "bottom" is never cleared.

---

I see two possible follow-up tasks:

• Prevent duplicate values: Should validator accept same values for an array-enum property? #8370, which would make step (2) from the second example impossible.
• Always clear all preferences whenever text-variable-anchor changes via setPaintProperty / setStyle.

That said, I think this PR gets us pretty far and unblocks Studio well enough.

[asheemmamoowala]

Prevent duplicate values: #8370, which would make step (2) from the second example impossible.

The de-duplication is also ticketed out in #8445

Always clear all preferences whenever text-variable-anchor changes via setPaintProperty / setStyle.

With #8399 this will require clearing out the preferred placement for multiple properties.

[peterqliu]

🚢

[pozdnyakov]

LGTM!

[pozdnyakov]

Port on gl-native: mapbox/mapbox-gl-native#15129