The general goal is to avoid displaying "Not enough memory available to check
for upgrades" too often due to over-cautious memory requirements checked in
the wrapper.

The specific goal is to avoid having to bump the hardware requirements for
Tails 1.1 (Wheezy) to >> 1 GiB of RAM, as this would 1. not be very nice for
users of oldish hardware; and 2. force us to implement #5502 ("Notify user if
hardware requirements are not met") in time for the 1.1 freeze.

My experiments, documented on #5390, indicate that even lower limits would
probably work. Let's not be too adventurous to start with, though: my plan is to
lower the limit to something that is low enough for the wrapper to dare running
the check for upgrades, but still quite cautious.

Later on, we could try lowering the limits even more, or even drop it entirely:
this would require a mechanism to detect when the check for upgrades fails due
to memory exhaustion, which don't have yet.

Note that, if an automatic upgrade is available, Tails Upgrader checks memory
again, to ensure there's enough free memory to apply the upgrade. This commit
assumes that Tails Upgrader's own check is cautious enough, and that we were not
implicitly relying on the check done earlier, in the wrapper, to ensure upgrade
safety. This assumption might be wrong. My plan is to use the incremental
upgrade to 1.1~rc1 as a test bench to verify this, as I have no time to fully
test this fully right now (still, I successfully applied a small — 50 MiB —
IUK on top of a current build from this very branch, with 126 MiB of free
memory, and 700 MiB total free memory).

The symptom of a failed upgrade due to lack of memory (and then, of a too low
$mem_factor value in Frontend.pm) would be to see the upgrader that simply die
in the middle of the download, or (worse) in the middle of the upgrade. In the
worst case, the resulting (partially upgraded) system may not boot anymore, but
no user data will be affected, and the user can still fix their stick by doing
a full upgrade.