[over.match] clarify whether [over.built] and surrogate candidates are functions

[zygoloid]

We sometimes talk about "candidate functions", and sometimes merely about "candidates" which may or may not be functions (eg, in the definition of "viable candidate"). We should be consistent.

Either we should describe (at least) [over.built] as introducing non-function candidates or we should change the places that say "if overload resolution selects a function [...]" to say what happens if it selects a "function" from [over.built].

Similar questions apply for surrogate candidates, where there are two "functions" in scope: the real operator T function and the invented surrogate call function. We should decide whether we consider the latter to be a function or not.

Similar questions apply for rewritten candidates. Are those candidate functions or not?

[jensmaurer]

Looking at [over.match], this is a bit messy. I agree that it would be technically more correct to talk about "candidates" to be inclusive towards built-in functions, rewritten candidates, and surrogate call functions. That's a major editorial rewrite of [over.match], though, replacing (for example) "best viable function" with "best viable candidate" etc.
That said, it seems we're careful to introduce function-like declarations even for built-in and rewritten candidates so that we can meaningfully talk about a "parameter type", for example.

I can't find a lot of places where we say "if overload resolution selects X". Where the phrase appears, X is so specific (e.g. "member function" or "constructor") that the non-function options are excluded regardless.