In particulate, an alternate version of switch tables
was being mis-detected by FII.  In particular, switch
tables were assumed to be size=4, but we found size!=4
in sqlite (in particular, size=8).  And, I know windows
binaries have size=1,2.

Also fixed an issue where lea reg1, [reg2+reg3] assumed reg2/reg3
had values (i.e., reg2 is the base address of a switch table),
when reg3 might have the value.  Fixed the assumption by
tracing both reg2+reg3.

Some minor code cleanups.

ZS-86 issue in parsing dynsym section.

See merge request !12

ZS-86: Dealt with sledding and KS-asm issues

See merge request zipr-be!19

The dynsym section is parsed by objdump/grep.  It's terrible and
needs to be implemented in C++ to reduce dependence on external tools
knowing what they are doing.

In this case, the terrible pattern matching with grep caused a symbol
defined in the binary to be missed, because `grep -v UND` was used
to determine whether a symbol "mattered".  1) symbol names might have
UND and get eliminated accidentally, but 2) (what really happened)
was that the symbol was defined in a section without a "link" field
in the dynsym section, thus objdump displayed the section name as UND
and thus the code skipped the symbol.  Don't use objdump to parse ELF
files!

Large ints as constant operands are weird in ks-asm.  Need to use
positive value, in hex, for less than max-signed-int, and negative
hex values for values between max-signed-int and max-unsigned-int.

Rida: Parsing of .plt.sec section added for x86/64 ubuntu 20 needed to be
updated to support x86/32 in ubuntu 20.

Fix-calls: Thunk checks aged poorly.  Revived/fixed some of them.

Shared libs need a reloc for a code pointer to live in rodata.
I found in ffmpeg that many spurious pins were occuring because constant
(particularly with relatively small values) data looked like code poitners
(because the code's load point is address 0 in a shared library).

To avoid these spuriosu pins, I extended the code pin algorithm
to check isDLL() (which includes shared objects) and for a reloc
before attempting to pin in the rodata.

A perf. optimization verifies that it _might_ result in a pin
before checking for a reloc, as checking for a reloc can be slow,
while checking for a possible pin location is fast.