Improve package search

[mikadoZero <mikadozero@yandex.com>]

# Motivation

From Ludovic Courtès response to bug#34828:
> "I would recommend against turning descriptions into lists of commands
> just for the sake of package search (we should instead have another
> mechanism to determine which package provides a given command) ..."

`guix package -s` often returns no useful results for a program that is
part of a larger multi program package with a different name.  This is
heightened by the very reasonable desire to prevent descriptions form
turning into lists of commands.

# Examples

Here two examples of programs that do not have useful package search
results:

`as` in `gcc-toolchain`
`recsel` in `recutils`

There are other programs that also have this issue.

# Proposed idea

* Add a "programs" field to package definitions that list the programs
  that are included in a package. 
* Include this field in search results.
* Have this field factor into the search result relevance scores.

# Implementation

I am not familiar with how package search works and do not know how
much work this would be to implement.

A requirement for a "programs" field could be included in package
linting.  I am not familiar with the inner workings of linting and do
not know how much work this would be to implement.

# Roll out

* New packages could be given the "programs" field when they are
  created.
  
* Existing packages that are being updated could be given the "programs"
  field.

* Existing packages with relevant irc questions or bug reports could
  be given the "programs" field.

* Existing packages without relevant irc questions or bug reports that
  are not being updated could remain unchanged.  This could save
  significant effort as many programs may never require the "programs"
  field to be added.

# Advantage

Allow users to better find what package includes the program they want
to install.

# Disadvantage

More effort required to package multi program packages.

I know that the coreutils package includes a very large number of
programs.  I do not know if there are many other packages that are also
as large.

# Feedback

This is an initial idea that would benefit from the input of others.

Given the uncertainties I mention in the Implementation and
Disadvantages sections this may not be a good solution for the
Motivation section.