This refactors ConfigParser double-quote parsing near the single
line double-quoted value parsing code, so that:

- Code that parses the name is less intermixed with code that
  parses the value.

- Conditional logic is less duplicated.

- The `END` comment notation appears next to the code it describes.

- The final `else` can be turned into one or more `elif` followed
  by `else` to cover different cases of `"..."` differently. (But
  those are not added here. This commit is purely a refactoring.)

(The `pass` suite when `len(optval) < 2 or optval[0] != '"'` is
awkward and not really justified right now, but it looks like it
may be able to help with readabilty and help keep nesting down
when new `elif` cases are added.)

These are cases where just removing the outer quotes without doing
anything to the text inside does not give the correct result, and
where keeping the quotes may be preferable, in that it was the
long-standing behavior of `GitConfigParser`.

That this was the long-standing behavior may justify bringing it
back when the `"`-`"`-enclosed text contains such characters, but
it does not justify preserving it indefinitely: it will still be
better to parse the escape sequences, at least in the type case
that all of them in a value's representation are well-formed.

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.)