Search backend: add support for negated predicates

[camdencheek]

For most of our predicates, we can theoretically support negation. Up until now, we've explicitly disallowed negating predicates because their implementation (expanding the predicate in the query) was not performant enough to work at all unless the negation somehow excluded almost everything (-repo:contains.file(.*)?).

Now that we implement all our predicates natively, negation is actually within reach. In fact, when I rewrote our predicates, I rewrote most of them with negation in mind, so it's not a super big lift to start enabling it.

This PR removes the "predicates are not allowed to be negated" rule and enables negation for repo:contains.file(), repo:contains.content(), repo:has(key:value), and repo:has.tag(t).

Stacked on https://github.com/sourcegraph/sourcegraph/pull/40280
Closes #24325
Fixes https://github.com/sourcegraph/sourcegraph/issues/41475

Test plan

Added many integration tests. Manually tested with local repo set.

[sourcegraph-bot]

Codenotify: Notifying subscribers in CODENOTIFY files for diff a8b4a34...edaba2d.

Notify	File(s)
@beyang	internal/search/query/predicate.go internal/search/query/predicate_test.go internal/search/query/types.go internal/search/query/validate.go internal/search/query/visitor.go internal/search/query/visitor_test.go
@keegancsmith	internal/search/query/predicate.go internal/search/query/predicate_test.go internal/search/query/types.go internal/search/query/validate.go internal/search/query/visitor.go internal/search/query/visitor_test.go
@rvantonder	internal/search/query/predicate.go internal/search/query/predicate_test.go internal/search/query/types.go internal/search/query/validate.go internal/search/query/visitor.go internal/search/query/visitor_test.go
@unknwon	dev/gqltest/search_test.go

[camdencheek]

This felt like the cleanest way of supporting negation in predicates. It allows each predicate to control whether it errors when negated, and we also already use this method to validate predicates during the validation step. It does somewhat blur the line between parsing, validation, and concrete representations, but I think we were actually already there. I renamed this to Unmarshal() from Parse() to reflect this.

[camdencheek]

This was the blanket "predicates do not support negation" error that is no longer needed.

[rvantonder]

needs changelog entry, yes? closes https://github.com/sourcegraph/sourcegraph/issues/24325 yes?

[camdencheek]

needs changelog entry, yes?

ah, yep. I've got some changelog debt from predicates changes.

closes https://github.com/sourcegraph/sourcegraph/issues/24325 yes?

Sure enough. I forgot we had an issue for this

[camdencheek]

Interface change: ParseParams is now Unmarshal to reflect the standard go idiom of mutating the struct being unmarshalled into. Additionally, at the point we unmarshal, we also store whether the predicate was negated (or error if not negated).

[camdencheek]

Note that the changelog does not include repo:has.tag() and repo:has(key:val) because those have not been announced/released yet, and will be tagged as experimental features for 4.0.

[camdencheek]

Re-requesting review because this got a little stale and getting it updated required non-trivial changes.

[tbliu98]

🚀

[rvantonder]

Cool! Curious to test on Sourcegraph.com to get a sense of how well this behaves :-)