review filtering guide

[maryamsulemani97]

closes #1902, #860, #837, and #1850

• moves all operators to a new heading
• removes SQL syntax and combines it with the curl code samples
• replaces amazon and imdb images for facets with meilisearch demo images
• removes unused images in .vuepress/public/faceted-search
• remove redundant code samples

---

• Improve coherence between dataset and examples
  • A sample document was added as part of Add code samples for sorting/filtering nested fields #2050 with rating and director fields
  • This PR uses movie_ratings instead of movies to clarify that this is a separate dataset
    • faceted_search_facets_1 still uses movies as this code sample is used in the API reference as well

[guimachiavelli]

I think we're almost there, but I have an extra comment regarding document structure.

In "Filter basics" we introduce two important terms: filter expressions and conditions. Though we give extensive definitions of conditions, filter expressions are only briefly defined mid-sentence on L#60. Since we use the term "filter expressions" throughout the document, I'm afraid inattentive users might have a hard time finding that definition because it's so easily missed—a quick scroll will not reveal any relevant headings and they will have to do a cmd+f and type "expression", possibly having to skip a few matches until they find a satisfactory explanation.

I can think of at least two ways of helping these users:

1. having a short section named "Filter expressions" with a definition and a code sample. For example:

### Filter expressions

Filter expressions combine multiple conditions with operators. They are always written in the `condition1 OPERATOR condition2` format:

```
genre = horror AND release_year > 2001
```

2. adding a brief definition of filter expressions to "Combining filter expressions". Could also involve changing this heading to something like "Combining conditions into filter expressions" (probably not a good title, but you get the idea)

I think #1 is simpler, but might be overkill.

[maryamsulemani97]

In "Filter basics" we introduce two important terms: filter expressions and conditions. Though we give extensive definitions of conditions, filter expressions are only briefly defined mid-sentence on L#60. Since we use the term "filter expressions" throughout the document, I'm afraid inattentive users might have a hard time finding that definition because it's so easily missed—a quick scroll will not reveal any relevant headings and they will have to do a cmd+f and type "expression", possibly having to skip a few matches until they find a satisfactory explanation.

I renamed the heading "Combining filter expressions" to "Filter expressions". That should make it more visible:

I didn't add "They are always written in the condition1 OPERATOR condition2 format:" because you can only use AND or OR. Both of them are mentioned in the first sentence of the paragraph and are subheadings

[guimachiavelli]

@dichotommy, you mentioned you wanted to review this. Will you have time for it?

[dichotommy]

Looks pretty good! I'm submitting half my review now so you can get started on it, will be back later to review the rest.

[dichotommy]

On y va! 🚀

[maryamsulemani97]

bors merge

[bors]

This PR was included in a batch that successfully built, but then failed to merge into main. It will not be retried.

Additional information:

Response status code: 422
{"message":"1 review requesting changes and 1 approving review by reviewers with write access.","documentation_url":"https://docs.github.com/articles/about-protected-branches"}

Na

[maryamsulemani97]

bors merge

[bors]

Build succeeded:

• check-builds (14)
• check-builds (16)
• check-links
• check-style
• vale