renovates the LLVM backend

[ivg]

renovates the LLVM backend

Droping support of old LLVM and legacy backends

We drop a lot of old code (minus 3k lines of code) thus removing the support
burden and making it easier to maintain, fix, and upgrade the code.

Fixes #1166

Simplifies the implementation

The remaining code base is significanly simplified. We dropped the
separation between relocatable and non-relocatable files, removed any
transformations of addresses from the LLVM backend (we now emit
absolute virtual addresses). The whole logic of transforming from the
llvm view to the bap image view now fits into a hundred lines of
code (instead of hundreds lines spread across 16 files as it was
before).

Fixes #1183
Fixes #1189

Produces more information

The relocation information is now emitted for all files (not only for
relocatable). Also, removes tons of checks that were preventing our
backends from emitting valuable symbolic information.

Paves the road to #1135 and #1161

[XVilka]

Relocatable files are probably PI[C|E] ELFs?

• https://codywu2010.wordpress.com/2014/11/29/about-elf-pie-pic-and-else/
• https://eklitzke.org/position-independent-executables

[gitoleg]

Speaking about relocatable files, I didn't mean just files with relocations, but files that contain a code that will be relocated, i.e. code that will be linked at some different address.
https://refspecs.linuxbase.org/elf/gabi4+/ch4.intro.html

Such files can contain symbols with no address assigned. For example, in the Elf_sym struct, the st_value field contains symbol address for the executable files but can contain any other value, depending on the file type or even ABI, and we shouldn't try to use this field as an address.

https://docs.oracle.com/cd/E19683-01/816-1386/6m7qcoblj/index.html#chapter6-35166

Also, in LLVM 3.8 (and maybe 3.4 as well), an attempt to access relocations of an executable file would fail the whole bap application, so we had to treat them separately.

Speaking about MachO, I still believe that something should be done:
for our testsute/x86_64-macho-obj, bap and objdump show different addresses for the first symbol: it's 1d0 for the former and 0 for the latter.

[ivg]

The main misconception that your brought into the implementation is that relocations could only happen in the relocatable files, while the only difference is that relocatable files do not have any fixed virtual addresses so we have to give them some base and this base must be more or less in sync with the state-of-the-art tools.

As this PR shows, we can easily handle relocatable files by just making the base calculation more robust and amend it for the relocatable files. The issue that I have with the current implementation, is that we are not providing a lot of valuable information, for non-relocatable files, e.g., the rellocations itself, indirect symbols, external symbols, etc. Again, all these features commonly occur in regular binaries. But this is a topic for another PR. This should be considered done. We have fixed macho and cleanup ELF and removed lots of unnecessary code. Everything else will be tracked in #1189. See also #1188 where I also significantly refactored the loader part and introduced proper namespaces for properties. I will rebase #1188 once this PR is merged.