pretty: Add failing tests: user format ignores i18n.logOutputEncoding setting

The following two commands are expected to give the same output to a terminal:

	$ git log --oneline --no-color
	$ git log --pretty=format:'%h %s'

However, the former pays attention to i18n.logOutputEncoding
configuration, while the latter does not when it format "%s".
Log messages written in an encoding i18n.commitEncoding which differs
from terminal encoding are shown corrupted with the latter even
when i18n.logOutputEncoding and terminal encoding are the same.

The same corruption is true for
	$ git diff --submodule=log
and
	$ git rev-list --pretty=format:%s HEAD
and
	$ git reset --hard

Signed-off-by: Alexey Shumkin <zapped@mail.ru>
pretty: user format ignores i18n.logOutputEncoding setting

The following two commands are expected to give the same output to a terminal:

	$ git log --oneline --no-color
	$ git log --pretty=format:'%h %s'

However, the former pays attention to i18n.logOutputEncoding
configuration, while the latter does not when it format "%s".
Log messages written in an encoding i18n.commitEncoding which differs
from terminal encoding are shown corrupted with the latter even
when i18n.logOutputEncoding and terminal encoding are the same.

The same corruption is true for
	$ git diff --submodule=log
and
	$ git rev-list --pretty=format:%s HEAD
and
	$ git reset --hard

Signed-off-by: Alexey Shumkin <zapped@mail.ru>
format-patch: cover letter does not respect i18n.commitencoding

When we write a cover letter it is naturally enough to suppose
that we use the same encoding as we do commits in. So make
"format-patch --cover-letter" to use i18n.commitencoding setting
in "Content-Type" header of a cover letter instead of hard-coded "UTF-8".
Especially as cover letter contains shortlog and diffstat of patches
which can contain author names and file names in i18n.commitencoding.
send-email: Honor multi-part email messages

"git format-patch --attach/--inline" generates multi-part messages.
Every part of such messages can contain non-ASCII characters with its own
"Content-Type" and "Content-Transfer-Encoding" headers.
But git-send-mail script interprets a patch-file as one-part message
and does not recognize multi-part messages.
So already quoted printable email subject may be encoded as quoted printable
again. Due to this bug email subject looks corrupted in email clients.
post-receive-email: explicitly set Content-Type header

Some email clients (e.g. claws-mail) incorrectly display
message body when there is no Content-Type header and charset
explicitly defined.
So, set explicitly Content-Type header. Its charset
can be defined with hooks.emailcharset config variable.

NB: This above-mentioned charset may differ from i18n.logOutputEncoding,
because e.g. gitweb expects (for now) i18n.logOutputEncoding set to UTF-8
to display logs correctly.

Also, introduce hooks.gitopts config variable
with the default '-c core.quotepath=false'.
This takes into account that we want to see pretty email-message
with well-looking messages and list of changed filenames.
And usually non-ASCII filenames are in the same
encoding that commit messages are.

Signed-off-by: Alexey Shumkin <Alex.Crezoff@gmail.com>
gitweb: Configurable hyperlinking

Commit messages of many projects refer to issues of bugtracking
systems, e.g.'Fixed: #NNN...'. This adds an ability to convert such strings
to hyperlinks leading to a corresponding issues in bugtracking system.
Configurable hyperlinking in gitk

Many projects use project-specific notations in changelogs to refer
to bug trackers and the like.  One example is the "Closes: #12345"
notation used in Debian.

Make gitk configurable so that arbitrary strings can be turned into
clickable links that are opened in a web browser.

Signed-off-by: Jeff Epler <jepler@unpythonic.net>
git-web--browser: avoid errors in terminal when running Firefox on Windows

Firefox on Windows by default is placed in "C:\Program Files\Mozilla Firefox"
folder, i.e. its path contains spaces. Before running this browser "git-web--browse"
tests version of Firefox to decide whether to use "-new-tab" option or not.

Quote browser path to avoid error during this test.