Proposal: Allow servers to customize the matching behavior of workspace symbols

A server may want to have a its own grammar for a workspace symbols request. For example, rust-analyzer supports * and # modifiers (meaning search in dependencies and search non-types, respectively), and I want to extend it to support fully-qualified searches, aka. foo::bar::Baz that will search Baz in bar module in foo.

Such search does not currently work in VSCode (but does in other clients), because VSCode self-filters the responses if they don't fully contain the query. That is solvable; I implemented a fix for that in VSCode. The problem is that even with this fix, VSCode (and probably other clients too) score and highlight results based on the query, which leads to non-ideal result, like searching for string::string brings the obvious full-match std::string::String (displayed to VSCode as String) be shown way after StringTooLongError, because the latter also match, in addition to the full String, "tng" from the second string, so it has a higher score. Plus the tng are highlighted, which looks very strange.

I propose we allow servers to redefine the query, that is, send the client the part they should match against. In particular, extend the protocol with the following properties:

interface WorkspaceSymbolClientCapabilities {
    /**
     * Support for a response of type `WorkspaceSymbols`.
     */
    objectResponse: boolean;

    // ...
}

/**
 * The response of a Workspace Symbols Request.
 */
interface WorkspaceSymbols {
    /**
     * The query to match and score against. Usually this is part of or the full `WorkspaceSymbolParams.query`.
     */
    query: string;

    /**
     * The list of symbols.
     */
    symbols: SymbolInformation[] | WorkspaceSymbol[];
}

And define the type of a response to a Workspace Symbols Request to be WorkspaceSymbols | SymbolInformation[] | WorkspaceSymbol[] | null.

Start by reviewing the WorkspaceSymbolClientCapabilities and Workspace Symbols Request definitions in the protocol, then trace the current response types for workspace symbol requests. Compare the proposed WorkspaceSymbols shape with the existing SymbolInformation[] and WorkspaceSymbol[] alternatives. Done means the protocol clearly represents the optional query used for client matching while preserving the existing response forms.