In query parameters, the `string` should take priority over others

[eemeli]

Pontoon presents the translation view state using query parameters, such as ?search=foo&string=123456. This is good in the moment, but our handling of older links could be improved. For example, let's say that a user links from elsewhere to an unreviewed string, with a query like ?status=unreviewed&string=123456. Later, after this string is reviewed, following that link will not lead to string 123456, but to some other unreviewed string.

We should change how we do fallback when the query includes a string parameter does not as a whole match a string. At the moment, we strip out the string, but I think we should instead do the opposite, and keep it while stripping out any non-matching query parameters.

[mathjazz]

Isn't this essentially the current behavior, but it feels weird, hence the #3148?

[eemeli]

The current buggy behaviour is due to always including the string parameter's match in the results. To see this bug in action, navigate to some filtered view with only a few results, and replace the string parameter in the URL with something non-existent like 99999999; you'll get an additional toast "Can't load specified string", but otherwise it matches the behaviour described here.

Once #3148 is fixed, when we get a query that has a string value that's valid but doesn't match the other URL parts, we should not just drop the string value, but display something like a 404 page that lets the user decide which way to go: path+filters or string id.