Before that, applying multiple changegroups in the same transaction issued the
message multiple time. This result in a confusing output:

    adding changesets
    adding manifests
    adding file changes
    added 32768 changesets with 60829 changes to 2668 files
    adding changesets
    adding manifests
    adding file changes
    added 8192 changesets with 16885 changes to 1553 files
    adding changesets
    adding manifests
    adding file changes
    added 1020 changesets with 1799 changes to 536 files
    adding changesets
    adding manifests
    ...

Instead, we now only issue the message once at the end of the transaction,
summing up all added changesets, changes and files. The line is identical, but
happens sightly later in the output.

There are other suboptimal behavior around issue multiple changegroup (eg:
progress bar). We'll cover them later.

This impact of lot of test as one would expect, but a two pass check show they
are just the order change we expected.

To deal with "under the hood" bundle application by internal code, we had to
take a slightly hacky move. We could clean that up with a more official way to
enter "under the hood" section, however I want to keep this series simple to get
it landed. This kind of change have a very high bit rot rate since it impact a
lot of test output.