dotnet-suggest assumes that dotnet global tools support the [suggest] directive

[GlobalToolsSuggestionRegistration](https://github.com/dotnet/command-line-api/blob/209b724a3c843253d3071e8348c353b297b0b8b5/src/System.CommandLine.Suggest/GlobalToolsSuggestionRegistration.cs) returns suggestion registrations for all executables in ~/.dotnet/tools/, and `dotnet-suggest` can then run such executables with the `[suggest]` directive even if they have not been explicitly registered. However, supporting this directive is not a requirement for [creating a .NET tool](https://docs.microsoft.com/dotnet/core/tools/global-tools-how-to-create). For example, dotnet-runtimeinfo 1.0.4, dotnet-script 1.1.0, and microsoft.visualstudio.slngen.tool 8.5.0 do not support it. There is a risk that the tool does something unexpected when given '[suggest]' which it does not recognize as a directive. For example, it could create a file with that name, or spend time trying to connect to a computer with that name.

I think the best solution would be:

1. Add something into the DotnetToolSettings.xml file to indicate that the command supports `[suggest]`. If it becomes possible to have multiple commands in the same tool package, this information should be specific to each command. The [GenerateToolsSettingsFile](https://github.com/dotnet/sdk/blob/8daa5f75dfc7592e30e28e71d448621d12442893/src/Tasks/Microsoft.NET.Build.Tasks/GenerateToolsSettingsFile.cs) task in .NET SDK generates DotnetToolSettings.xml and could read some property that the System.CommandLine package would set by default.
2. Make `dotnet tool install` copy this information to some place from which `dotnet-suggest` can find it, regardless of whether `dotnet-suggest` has been installed. For example, place it in ~/.dotnet/tools-suggest.json, or copy the whole XML file to tools/.meta/command/DotnetToolSettings.xml.
3. Make `dotnet-suggest` consult the information from step 2 to ascertain whether the command supports `[suggest]`.

If a tool supports `[suggest]` but is too old to include this information in its DotnetToolSettings.xml file, then the user can `dotnet-suggest register` it manually.

I also considered adding some AssemblyMetadataAttribute to the entry point assembly of the command, but that doesn't really seem any easier because the executables in ~/.dotnet/tools/ are shims that don't contain CLR metadata. Also it would not be so easily extensible to wholly unmanaged tools.