gitpython-developers#2035 fixed issue gitpython-developers#1923 by removing separate double quotation marks
appearing on a single-line configuration variable when parsing a
configuration file. However, it also stripped leading and trailing
whitespace from the string obtained by removing the quotes.

This adds a test case of a plausible scenario where such whitespace
needs to be preserved and where a user would almost certainly expect
it to preserve: setting a value like `# ` for `core.commentString`,
in order to be able to easily create commit messages like this one,
that contain a line that begins with a literal `#`, while still
letting `#` in the more common case that it is followed by a space
be interpreted as a comment.

The effect of  `git config --local core.commentString '# '` is to
add a `commentString = "# "` line in the `[core]` section of
`.git/config`. The changes in gitpython-developers#2035 allow us to correctly parse
more quoted strings than before, and almost allow us to parse this,
but not quite, because of the `strip()` operation that turns `# `
into `#`.

At least in a single line, whitespace in a double-quoted value in a
configuration file, like `name = " abc def "`, would presumably be
intended. This removes the `strip()` call that is applied to text
`ConfigParser` obtained by removing the double quotes around it.

This slightly refines the changes in gitpython-developers#2035 by dropping the `strip()`
call while continuing to remove opening and closing double quotes.

In both the:

- Unquoted case, where extra whitespace is at the edges of what can
  be parsed as the value.

- Quoted case, where extra whitespace is next to but outside of the
  quotes.

The case where the whitespace is at the edges of the quoted value
and *inside* the quotes, and thus part of the value, is already
covered in gitpython-developers#2036. (That is merely renamed here, to distinguish it.)

This is for single line quoting in the ConfigParser.

This leaves the changes in gitpython-developers#2035 (as adjusted in gitpython-developers#2036) intact for
the cases where it addressed gitpython-developers#1923: when the `...` in `"..."`
(appearing in the value position on a single `{name} = {value}"`
line) has no occurrences of `\` or `"`, quote removal is enough.

But when `\` or `"` does appear, this suppresses quote removal.
This is with the idea that, while it would be better to interpret
such lines as Git does, we do not yet do that, so it is preferable
to return the same results we have in the past (which some programs
may already be handling themselves).

This should make the test introduced in the preceding commit pass.
But it will be even better to support more syntax, at least
well-formed escapes. As noted in the test, both the test and the
code under test can be adjusted for that.

(See comments in gitpython-developers#2035 for context.)

This is for single line quoting in the ConfigParser.

This leaves the changes in gitpython-developers#2035 (as adjusted in gitpython-developers#2036) intact for
the cases where it addressed gitpython-developers#1923: when the `...` in `"..."`
(appearing in the value position on a single `{name} = {value}"`
line) has no occurrences of `\` or `"`, quote removal is enough.

But when `\` or `"` does appear, this suppresses quote removal.
This is with the idea that, while it would be better to interpret
such lines as Git does, we do not yet do that, so it is preferable
to return the same results we have in the past (which some programs
may already be handling themselves).

This should make the test introduced in the preceding commit pass.
But it will be even better to support more syntax, at least
well-formed escapes. As noted in the test, both the test and the
code under test can be adjusted for that.

(See comments in gitpython-developers#2035 for context.)

This is for single line quoting in the ConfigParser.

This leaves the changes in gitpython-developers#2035 (as adjusted in gitpython-developers#2036) intact for
the cases where it addressed gitpython-developers#1923: when the `...` in `"..."`
(appearing in the value position on a single `{name} = {value}"`
line) has no occurrences of `\` or `"`, quote removal is enough.

But when `\` or `"` does appear, this suppresses quote removal.
This is with the idea that, while it would be better to interpret
such lines as Git does, we do not yet do that, so it is preferable
to return the same results we have in the past (which some programs
may already be handling themselves).

This should make the test introduced in the preceding commit pass.
But it will be even better to support more syntax, at least
well-formed escapes. As noted in the test, both the test and the
code under test can be adjusted for that.

(See comments in gitpython-developers#2035 for context.)

This is for single line quoting in the ConfigParser.

This leaves the changes in gitpython-developers#2035 (as adjusted in gitpython-developers#2036) intact for
the cases where it addressed gitpython-developers#1923: when the `...` in `"..."`
(appearing in the value position on a single `{name} = {value}"`
line) has no occurrences of `\` or `"`, quote removal is enough.

But when `\` or `"` does appear, this suppresses quote removal.
This is with the idea that, while it would be better to interpret
such lines as Git does, we do not yet do that, so it is preferable
to return the same results we have in the past (which some programs
may already be handling themselves).

This should make the test introduced in the preceding commit pass.
But it will be even better to support more syntax, at least
well-formed escapes. As noted in the test, both the test and the
code under test can be adjusted for that.

(See comments in gitpython-developers#2035 for context.)

This is for single line quoting in the ConfigParser.

This leaves the changes in gitpython-developers#2035 (as adjusted in gitpython-developers#2036) intact for
the cases where it addressed gitpython-developers#1923: when the `...` in `"..."`
(appearing in the value position on a single `{name} = {value}"`
line) has no occurrences of `\` or `"`, quote removal is enough.

But when `\` or `"` does appear, this suppresses quote removal.
This is with the idea that, while it would be better to interpret
such lines as Git does, we do not yet do that, so it is preferable
to return the same results we have in the past (which some programs
may already be handling themselves).

This should make the test introduced in the preceding commit pass.
But it will be even better to support more syntax, at least
well-formed escapes. As noted in the test, both the test and the
code under test can be adjusted for that.

(See comments in gitpython-developers#2035 for context.)