This is particularly worth doing because the latest git-annex release
(8.20200226) changes its treatment of dotfiles and removes
--include-dotfiles.

Unless git-annex is passed dotfiles explicitly, it skips them by
default.  This differs from git's behavior of adding the dotfiles
regardless of whether they are given as explicit pathspecs.  To make
'git annex add' behave more consistently with 'git add', AnnexRepo
passes --include-dotfiles to it in two independent spots, _save_add()
and add_().

However, git-annex version 8.20200226, specifically 3cd375723
(annex.dotfiles, 2019-12-26), drops --include-dotfiles and changes the
behavior described above: git-annex no longer skips dotfiles, but
instead adds them to git (unless instructed otherwise by
annex.dotfiles or annex.largefiles/--force-large).

Try to make the behavior more consistent with older git-annex versions
we support by

  * continuing to use --include-dotfiles if it is available.  We cache
    its availability in a new class method.  Note that the method is
    written in a more general way to anticipate the need for more such
    kludges, including the new --force-{large,small} options.

  * Unconditionally use '-c annex.dotfiles=true' in our git-annex
    calls so that the addition of dotfiles honors annex.largefiles and
    friends, like they do in earlier git-annex versions.

At this point, the main behavior discrepancy that we expose between
8.20200226 and earlier versions is that `repo.add(<directory>,
git=False)` will _not_ skip dotfiles with 8.20200226 while it will
with older versions.  This doesn't seem worth worrying about because
core.local.save()/repo._save_add() aren't susceptible to this issue
because they deal with status-expanded paths (i.e. they don't end up
calling `git annex add` with directories, making git-annex's old
dotfile skipping behavior irrelevant).

Re: datalad#4185
Re: datalad#4213

Right now, we only need to clean up the fsck() result in one spot, but
with 8.20200226, we also need to filter "error-messages" to several
spots.  Move this to a dedicated helper.

As of git-annex 8.20200226, test_publish_simple() and
test_publish_with_data() will fail because the remote=None fsck() will
include an message along the lines of

  test-annex.dat: Can be upgraded to an improved key format. You can
  do so by running: git annex migrate --backend=SHA256E test-annex.dat

These tests are failing on the Windows GitHub CI build with
8.20200226-g2d3ef2c07.  Due to the combination of an adjusted branch
and us using a `-c annex.dotfiles=true` override in our calls to
git-annex, the repos end up in an unexpectedly dirty state when on an
adjusted branch.  (Dotfiles switch from pointer files back to
git-tracked files.)

The issue goes away if we set annex.dotfiles in .git/config or
git-annex's config.  So the two main options seem to be to (1) not set
annex.dotfiles=true or (2) to set it more persistently.  The former
isn't likely to be viable because it would prevent use from annexing
content like ".datalad/metadata/objects/", and the latter needs more
thought.  For now, make these tests pass by adjusting them to set
annex.dotfiles=true in .git/config when running on an adjusted branch.

Re: datalad#4214 (comment)

The Windows GitHub CI builds are now running with
8.20200226-g2d3ef2c07.  The --include-dotfiles adjustment from this
series removed the widespread failures, and the previous commit worked
around unresolved issues due to adjusted branches and using `-c
annex.dotfiles=true`.  These are the remaining failures.

Re: datalad#4214 (comment)