bug#23076: 24.5; vc-git: add a new variable for log output coding system

[Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com>]

My suggestion was based on the idea that introducing a new variable is 
guaranteed to not break anyone's setup.

Solution 1 seems to be more dangerous in this regard.

Also #1 seems inferior to #2 for this case - what if you don't have 
control over system non-Unicode encoding? Let's say someone wants to 
commit org-mode notes in his native language, from a workplace, where he 
has no admin rights for the machine and no ability to change that 
windows setting. That's probably a rare case, but still, seems like 
something that may happen.

I also did some testing of #2 and noted this thing - the current git 
behaves somewhat weirdly in regards with git commitencoding and message 
files. That is:
1. Let's say your message.txt is encoded in windows-1251. Trying to 
commit it with "git commit -F message.txt" would result in a broken 
commit and this:
> Warning: commit message did not conform to UTF-8.
> You may want to amend it after fixing the message, or set the config
> variable i18n.commitencoding to the encoding your project uses.
2. Let's try doing so and set commitencoding to windows-1251 and commit 
again. Now we get no warning, but our message is a badly coded mess, 
though differently from the previous step, so it did something extra 
while encoding the message.
3. Even when our commitencoding = windows-1251 committing message.txt in 
utf-8 works fine.

So, it seems like we want to always use utf-8 for messages.

-- 
Best Regards,
Nikolay Kudryavtsev