search: calculate correct result count after intersecting results

Created by: rvantonder

When result sets are merged for and or or operators, it's possible that the result set size (length of list) becomes detached from the result count we keep track of in the common searched results. This can cause a nil-deref/slice-out-of-range for a query like ((main and func) or return) when we try and slice results than are calculated. This was introduced in #11482, but we should prefer not to revert this because it solves another issue.

This PR fixes the issue (no nil-deref/slice-out-of-range) so that it's not possible to slice out of range. The fix adds integration tests to cover this behavior. Previous tests didn't catch it because it only covered merge operations of and and or in isolation, and not in combination, which is needed to trigger this bug.

---

More details about the fix:

The PR accurately count content matches for merge operations now and will also update count based on result matches, but the change here also does not rely on count as a source of truth, and only rely on the the match result list for slicing results, since this list length may differ from the reported match count based on non-content matches like repositories (which we don't want to rely on for current and/or evaluation and are currently out-of-scope to accurately calculate when and/or queries are run).