Bug: git config does not respect read-only .gitconfig file

All,

I recently discovered that `git config` does not respect read-only files.

This caused unexpected difficulty in managing the global .gitconfig for a system account shared by a large team. A team member was able to execute a `git config --global` command without any notice or warning that the underlying config file had been marked read-only in an attempt to prevent unintentional changes. If instead git had raised a warning saying that the "gitconfig is read-only" this would have prevented that team member from accidentally breaking our git config.

Bug detail:

Due to the implementation strategy of config::git_config_set_multivar_in_file_gently ( https://github.com/git/git/blob/5b33cb1fd733f581da07ae8afa7e9547eafd248e/config.c#L2074 ) the file permissions of the target .gitconfig file are not respected.

Proposal:

Part 1) Add a .gitconfig variable to respect a read-only gitconfig file and optional "--force" override option for the `git config` command

Such a gitconfig variable could be defined as: config.respectFileMode: [ "never", "allow-override", "always" ]

Where:
* never - read-only file mode of config files are ignored (aka:
existing behavior)
* allow-override - read-only file mode of config files is respected
unless the user provides a "--force" option to `git config`
* always - read-only file mode of config files is respected (and the
"--force" option does not work)

Part 2) Change config::git_config_set_multivar_in_file_gently ( https://github.com/git/git/blob/5b33cb1fd733f581da07ae8afa7e9547eafd248e/config.c#L2077 ) to verify write permissions on the destination depending on the specified config.respectFileMode variable and "--force" option.

I think that this is a reasonably sized change that enables users to opt-in to a 'strict mode' while preserving current behavior.

Thoughts?

Tested with:
OS: Linux
Version: 2.9.0 (issue exists in current master branch)