This has each module use `__name__` for the path to its own logger.
Previously, most modules did this several hard-coded their names in
calls to logging.getLogger.

These globals were nonpublic, because even though they were named
without leading underscores, they all appeared in modules in which
__all__ was defined and did not list them. (They remain nonpublic.)

This renaming is to avoid confusion between those log attributes
ang logging features of Git itself ("git log", "git reflog"), and
more importantly, with the related git.refs.log module, referred to
by the log attribute of the git.refs module, and the log attribute
of the git module (git/__init__.py has a * import from git.refs).

This changes a couple tests that access specific loggers to use the
logger name instead, as code outside GitPython should do.

This stops adding `NullHandler` instances to GitPython's loggers.
As noted in gitpython-developers#1806, when they were added in gitpython-developers#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 is instead of the current behavior writing the message to
stdout.

This commit does not change the behavior of the code under test,
but it changes tests to assert the following:

- "Bad git executable" messages are logged, at level CRITICAL.
- "log" (and "l") is recognized as another synonym of "warn".
- "silent" is recognized as a synonym of "quiet" (as "silence" is).

Although it is ambiguous whether this should be logged at level
ERROR or CRITICAL, because git.refresh is still expected to be
usable and can be called manually, not having a working git is a
condition in which GitPython, and any program that really relies on
its functionality, should be expected not work. That is the general
rationale for using CRIICAL here. There are also two specific
reasons:

- Existing messages GitPython logs as ERROR typically represent
  errors in individual operations on repositories, which could fail
  without indicating that GitPython's overall functionality is in
  an unusable state. Using the higher CRITICAL level for this
  situation makes sense for contrast.

- Prior to gitpython-developers#1813, logging messsges emitted from GitPython modules,
  no matter the level, were suppressed when logging was not
  configured, but because this message was printed instead of
  being logged, it was still shown. Now that it is to be logged,
  there may be a benefit to have an easy way for someone to bring
  back a close approximation of the old behavior. Having this
  message be at a higher logging level makes that easier to do.
  (This is a less important reason, as that should rarely be done.)

test_initial_refresh_from_bad_git_path_env_warn is the main changed
test. All tests should pass again once code is changed for gitpython-developers#1808.