Match the REST change filters exactly and refuse the values that cannot be read

The GET /wikis/{wikiName}/releasenotes/{product}/{version}/changes endpoint reads its filters loosely:

• a mistyped value, e.g. audience=users, importance=huge, containsScreenshots=yes or limit=ten, is not refused: an audience or importance filter silently matches no change (the client gets an empty list it cannot tell from a real one), and the others silently fall back to their default;
• a value is matched as a pattern (% and _ are wildcards) and may carry an operator prefix (>=high), which is the syntax of the getChanges wiki macro and not what the endpoint documents ("the audiences to keep, comma separated");
• a parameter left empty (audience=) matches no change at all rather than filtering nothing.

The endpoint also reads each returned change a second time, checking the view right again for each one.

Proposed:

• each listed value is matched exactly; an empty parameter filters nothing;
• an unreadable value (unknown audience or importance, a screenshot filter other than true/false, a limit that is not a whole number of at least 1, a negative offset) is answered with 400 and a message naming the value;
• a new ChangeManager#searchAndLoad(ChangeQuery, Predicate) (returning a LoadedChangeSearchResult) gives the changes with their pages in one call, the view right being checked once, by the search filter, before the result is paged (as done for RN-122).

The getChanges wiki macro and its syntax are unchanged.