Don't suppress messages when logging is not configured

[EliahKagan]

Fixes #1806

This stops adding NullHandler instances to GitPython's loggers. As noted in #1806, when they were added in #300 this prevented errors when GitPython logged messages and logging was not enabled, but since Python 3.2 there is a logger of last resort providing a nicer default behavior of showing the messages. (They are still shown with better formatting if logging is configured, even if just done with logging.basicConfig(), so applications should still typically configure logging.)

This also makes a few more minor related changes, detailed in the commit messages. This includes changing variable names from log to _logger, as mentioned in #1806 (comment), as well as consistently passing __name__ to logging.getLogger instead of hard-coding names in a few places, as mentioned in #1808 (comment).

The major effect of the changes here is that messages of level WARNING or higher are not suppressed by default anymore, even when logging is not configured. So I could have included a change here to take care of #1808 as well, such as dc62096. But I plan to introduce that in a future pull request instead, because it would be best to add tests for it, which I think should build on the tests proposed in #1812. If both #1812 and this PR are merged, I can add tests followed by the changes from dc62096 that would make them pass. (If they are not merged, or they are merged with major changes, then that will also clarify how to move forward with making a warning from the initial refresh use the logging framework.)

This shows as resolving several CodeQL alerts and also adding new alerts that correspond exactly to them. This happens as a result of renaming log to _logger; CodeQL considers the alert resolved because there are no more calls to log, and issues new equivalent alerts for the same situations with _logger. The new alerts produce a failing Code scanning results check for the PR.