Do something more sensible for interpreting search patterns as part of repo search.

Created by: rvantonder

Problem:

Let's say there's two searches like this:

1. type:repo foo@bar

2. repo:qux foo@bar

Considering how we handle @ syntax, query (1) is or should be equivalent to repo:foo@bar, and so interpreting the search pattern foo@bar we can reasonably assume that the @bar part should be searched as a revision.

But in (2), consider that the user may just be searching for a pattern foo@bar, and not a revision @bar. Currently, our default kind of search will search for repos and content for the pattern foo@bar. But when it searches for repos, we have a problem: it now tries to interpret the @bar part as a revision, and might not find it! When it doesn't find it, we get an alert. But the user would probably be like "what? I didn't mean to search for that @bar as a repo revision, why do I see this?".

Between (1) and (2), we have different usability and validation properties we should care about. In query (1), we can be strict about validation (@bar should exist, since this is a type:repo search). In (2), we don't want to be this strict: we just want to suppress the case if @bar doesn't resolve to a revision for a repo search. Currently, our "repo search" logic has no way to distinguish between cases (1) and (2), and the stricter validation of (1) crops up in (2) as well. As a stopgap I've relaxed the validation/search behavior of patterns containing @ so that in the second case (2) we don't alert nonsensical things. It does mean that type:repo foo@bar implies we will just search type:repo foo. A better solution is to just tell users to use repo:foo syntax, and prefer rev:bar: strongly discourage @ syntax, and strongly discourage type:repo.

... Just one more reason to can type: and type:repo.