Filtering query for suggestions

[todvora]

This PR adds a possibility to define a filtering query to the suggestion request. This query should help to narrow down possible suggestions related to the query, as requested in https://github.com/Graylog2/graylog2-server/issues/12869

How Has This Been Tested?

Added integration test

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Refactoring (non-breaking change)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [x] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [x] I have added tests to cover my changes.

[luk-kaminski]

It is a very promising change, @todvora !

What I am concerned about:

1. Front-end will have some hard time preparing proper filtering_query. If I understood everything correctly, for this query: _exists_:destruction_method AND type:<cursor is here> AND NOT _exists_:vehicle FE has to know that AND type: AND needs to be cut out and only _exists_:destruction_method AND NOT _exists_:vehicle used for filtering_query.
2. Probably multiple occurrences of the same field should not be taken into consideration for filtering_query. For query type:tank AND type: you rather don't want to use type:tank to filter suggestions for the second type occurence, as it will simply limit your suggestion to tank value only...Another problem for FE?
3. Not to mention complexity of query with nested parenthesis and cursor somewhere in the middle...
4. Does it also have to work together with Search Filters ????

Which leads me to a doubt if FE shouldn't just throw all the data at BE (query string with cursor, streams, search filters) and BE should take all the havok of figuring out how to construct filtering_query ...