add needed scanmem extensions as patches
updated .gitignore
ugtrain.cpp: use 'pidof' instead of 'ps' magic to find the game PID
detect and fix compiler warnings
getch_l.c: improve restore_getch for general usage

The function restore_getch can't be used to also restore the non-
blocking state. It also doesn't check if the tty was actually
changed.

So make it do so to be able to use it also within the code to
restore the tty (e.g. for scanf stuff) and to prepare it again.
ugtrain.cpp: register restore_getch with atexit

This makes it simpler and safer. We don't need cleanup_exit
anymore.
add linuxhooking to hack dyn mem of chromium-bsu
configure.in: check for 32/64-bit cross compile

The memory discovery/hacking libraries must have the same architecture as
the victim process. Therefore, we compile these for 32 as well as 64-bit.
This makes most sense if you run a 32-bit victim process on a 64-bit system.
parser.cpp: enhance parsing for dyn. mem.
substitute some integer types
parser.cpp: enhance name and addr. parsing
ugtrain.cpp: fix and enhance cfg output for addrs and dyn. mem.
add chromium-bsu 32-bit example config
enhance dyn mem processing and FIFO permissions

Now, for checks and memory values the mem addr is calculated with a
memory offset (the addr returned by malloc or 0).

Furthermore, FIFOs get 666 permission. This is needed as in many
distributions the "ptrace" syscall requires root permission. If
you already have to run the trainer as root, you don't want to run
the game as root as well.
ugtrain.cpp: integrate dyn. mem. hacking

Now, we are able to read from the FIFO and to parse the data out
of it. With that we can really freeze dynamic memory from a
constructor.

Tested with the number of lives in the "HeroAircraft" object from
32-bit "chromium-bsu".
add float 32/64 support, always process mem 64-bit

We treat all floats as doubles when reading them. As a hacky trick
we copy them as double into the i64 value and from there back to
double for the output.
parser.cpp: allow numbers in names
ugtrain.cpp: fix dyn. mem. preparation

We had the issue that the same dyn. mem. config was sent multiple
times to the preloaded game process if multiple memory values are
configured within the same object. This is the fix for that.
add dyn. mem. object name to config parsing
add chromium-bsu64 dyn. mem. ugtrain example