avoid depends on std::string implementation for pkgAcquire::Item::Mode

In /experimental this is resolved by deprecating Mode and moving to a
new std::string, but that breaks ABI of course, so that was out of
question. We can't change to a malloc/free style c-string either as
Mode is public and hence a library user could be setting this as well.
std::string implementors actually helped us out here with copy-on-write
which means that while the variable "obviously" runs out of scope here,
in reality you get the correct result as the string we work with here
comes from the configuration in which it is still valid. Such a
dependency on magic is bad of course, but its still interesting that
only python3 seems to have an issue with it…

With some silly explicit if-else assigning we can sidestep this issue
while retaining the same output for 99.99% of all users (= noone
actually configures additional compression algorithms which are also
provided by repositories…), but even for these 0.01% its just a small
change in the display as Mode can not be used for anything else.
Example: apt/aptitude uses it in its 'update' implementations in the
one-line progress at the bottom for specific items.

Closes: 781858

apt-pkg/acquire-item.cc

@@ -1194,8 +1194,18 @@ void pkgAcqIndex::Done(string Message,unsigned long long Size,string Hash,
    Desc.URI = decompProg + ":" + FileName;
    QueueURI(Desc);
 
-   // FIXME: this points to a c++ string that goes out of scope
-   Mode = decompProg.c_str();
+   if (decompProg == "copy")
+      Mode = "copy";
+   else if (decompProg == "xz")
+      Mode = "xz";
+   else if (decompProg == "lzma")
+      Mode = "lzma";
+   else if (decompProg == "bzip2")
+      Mode = "bzip2";
+   else if (decompProg == "gzip")
+      Mode = "gzip";
+   else
+      Mode = "decomp";
 }
 									/*}}}*/
 // AcqIndexTrans::pkgAcqIndexTrans - Constructor			/*{{{*/