Add endpoint to fetch fluent reference variants

[julen]

Refs. #2363

In this changeset we introduce the /get-fluent-reference-variants/ endpoint
that allows consumers to retrieve any selectors and their variants as referenced
by a Fluent entity for a locale.

This endpoint requires an entity pk and a locale code.

The view:

• Returns an empty payload for non-Fluent entities; 400/404 for invalid input.
• Otherwise, the string is parsed as a Fluent entry, and any messages/terms
  referenced by it are collected.
• Each reference's entity definition is then queried by key in the project.
  Should there be multiple entities defining the same key (rare, but technically
  possible), the entity's own resource takes precedence.
• The translation to the requested locale is then fetched, and its variants
  extracted.

Fluent string parsing, message/term reference and selector variants extraction
has been implemented as free functions under fluent_utils.py, with unit tests.

These are directly leveraged by the XHR view that implements the business logic.
All code paths here contain integration tests.

Note this is the building block for the Fluent variants autocomplete feature
that will be implemented separately, so the endpoint is not being used yet.

[julen]

The diffstat is rather large for my taste, but it's mostly tests.

I have attempted to follow the existing project conventions, if there's something that I missed that needs adjusting, just let me know. Also if I misinterpreted any terminology around Fluent strings I'd be happy to be corrected -- this was the first time for me fiddling with the format as well as with its AST.

[julen]

Message is a union (not a class), so mypy was complaining. A more future-proof approach would be to place this check behind a TypeIs guard; let me know if you want that or not.

[eemeli]

Took a quick peek at this before I head off to PTO, so please dismiss my review if it gets stale:

As @mathjazz mentions in #2363 (comment), this API should be fetching all available terms in a project+locale, not just the ones referenced in a single entity. Terms are Fluent-only, and identifiable by their identifier starting with a hyphen-minus - character.

There also should be no need to do any parsing as a part of the work here.

[julen]

Thanks for the quick check before the PTO @eemeli!

I definitely misread the intent in #2363 (comment), but I now see the assumption and the trade-off makes sense.

re.

There also should be no need to do any parsing as a part of the work here.

I'm not super familiar with the data model, so correct me if I'm wrong, but as I see now Entity.value (as well as Translation.value) contain a JSON-serialized representation which should include the parsed parts, and this should be readable by the frontend already. Is this what you mean here?

[eemeli]

I'm not super familiar with the data model, so correct me if I'm wrong, but as I see now Entity.value (as well as Translation.value) contain a JSON-serialized representation which should include the parsed parts, and this should be readable by the frontend already. Is this what you mean here?

Yes. For Fluent terms, you'll also need to account for Entity.properties and Translation.properties. There are also some utilities here that may be useful, if you need to do more on the server than pass the JSON to the frontend.