Fixed problem where QEMU symbol info is wrong when executable segments don't start at 0x0.

[fadeopolis]

Problem:
With newer versions of GCC/binutils (for example on Fedora 29) the executable segment of executables and shared libraries no longer starts at offset 0x0.
When QEMU loads a file the following happens:
1. QEMU loads the binary via load_elf_image, which in turn maps in all segments via target_mmap.
2. target_mmap calls load_symbols_from_fd if a segment is mapped in as executable code (the load bias used is the start address of the segment, i.e. any original load bias + the offset at which the segment is loaded). load_symbols_from_fd then calls load_symbols with the passed load bias.
3. At the end load_elf_image calls load_symbols yet again to make sure symbols are loaded. Here the

When querying for symbol information QEMU will use the symbol info with the wrong load bias!

There are two problems here:
1. The load bias for symbol information loaded in step 2 is incorrect, it is actually real_load_bias+offset.
2. Symbol information is loaded & stored in memory at least twice for every normal executable & shared libary. (once with the correct load bias, once with the wrong one).

This patch only solves problem 1.
Problem 2 is not hard to solve, but requires more invasive changes to load_symbols from upstream.