Test suite: don't rely on mtimes from Debian packages we download, to indicate which one has the biggest version (refs: #16819).

These mtimes are copied from the HTTP server where APT downloads packages from.

In "Scenario: Recovering in offline mode after Additional Software previously
failed to upgrade and then succeed to upgrade when online", after we've done "I
prepare the Additional Software upgrade process to fail", the APT cache on
Buster has:

-rw-r--r-- 1 root root 20296 Apr  1  2018 cowsay_3.03+dfsg2-1_all.deb
-rw-r--r-- 1 root root 20856 Feb  5 01:06 cowsay_3.03+dfsg2-6_all.deb

… and we want the dpkg hook installed by this step to delete the one with the
largest version number, i.e. cowsay_3.03+dfsg2-6.

But the previous code, based on "ls -tr1 | head -n 1" would delete the file with
the oldest mtime (cowsay_3.03+dfsg2-1) when run on Buster, instead of
cowsay_3.03+dfsg2-6, so the upgrade we wanted to make fail succeeds,
and in turn this step fails:

  I see the "The upgrade of your additional software failed" notification after at most 300 seconds

FWIW, I think the previous code happened to work on Stretch merely because the
mtime of cowsay_3.03+dfsg2-1_all.deb in our custom APT repo was newer than the
one of Stretch's 3.03+dfsg2-3, since we had uploaded it at a later time.
But if a 3.03+dfsg2-3+deb9u1 was ever released, if my hypothesis is correct,
this test would start failing on Stretch in the exact same way.

Let's not rely on such mtimes and instead, use ls' ability to sort
by version number, to pick the biggest one.