Proposal: server-advertised config options

["Drew DeVault" <sir@cmpwn.com>]

The basic idea is that the server could advertise some config options
which it recommends the client sets for a given repo after a fetch. Some
possible use-cases for this feature include setting:

- format.subjectPrefix to 'PATCH my-project'
- sendemail.to to the mailing list address
- push.pushOption to recommended push options

Upon cloning, each recommended config option would be displayed to the
user, and they would be prompted ([Y/n]) to agree to set that value in
the config file for that repository. Additionally, there would be a
config option which white-lists a list of config options which are
automatically agreed to without prompting, and each config option would
have one of the following states:

- accept-silent: set the option without printing a message
- accept-verbose: set the option and display a message
- prompt: prompt the user to set this config option
- reject-silent: silently refuse to set this config option
- reject-verbose: refuse to set this config option and display a message

We would default to reject-verbose for all unknown config options and
include a set of defaults which specifies the appropriate trust level
for various useful benign options (such as the examples above).

The implementation would involve advertising config-advertisement in the
fetch protocol. Both the client and server would have to agree to use
it. If the server supports it but the client does not (in the case of an
old client), it could fall back to printing the list of recommended
options to stderr.

To choose which config options to advertise, a new option would be
introduced (uploadpack.advertiseOptions) for example, which has a list
of .git/config options from the remote repository to forward to the
client.

This would be a lot of work so I'd like to float it for discussion
before getting started. What do you guys think?