GeezerVison

git accepts yes/no and on/off for a boolean as well as true/false
(git_parse_maybe_bool_text in parse.c), and ConfigParser.getboolean on this
class already accepted all of them. _string_to_value handled only true/false,
under a comment claiming to "try boolean values as git uses them", so the two
accessors disagreed about the same file:

    value   get_value()   getboolean()   git config --type=bool
    yes     'yes'         True           true
    no      'no'          False          false
    on      'on'          True           true
    off     'off'         False          false

Returning them as strings was worse than merely inexact. "no" and "off" are
non-empty, so a caller testing the result of get_value got True for a value
git reads as false — the inversion is silent, since nothing raises.

_string_to_value now recognises the same spellings getboolean does. A value
that is not a boolean is untouched, so "meld" is still returned as a string,
and numeric values keep their existing behavior.

Not changed here: get_value also diverges on numeric bases and suffixes
("0x10" and "1k" come back as strings, "010" as 10 where git reads octal 8).
Those change the value rather than its type and are worth their own commit.

Validation: test_get_value_reads_git_boolean_spellings covers the ten
spellings and asserts the two accessors agree; it fails on the previous
revision. test/test_config.py passes (40 passed, 2 skipped), ruff check and
ruff format are clean. test/test_repo.py errors on this clone because
init-tests-after-clone.sh has not been run, unchanged by this commit.