tiff: drop sources and headers from the source tree

* also drop jpeg and png headers
Patch by dnivra (GSoC 2014, ARM suppport)

* Cleanup the SD card image building to allow jam -q @bootstrap-mmc to
work.

There are a few remaining tricks before you can safely build an image:
* This uses a non-POSIX du option, and is only tested with Linux du
only (Linux is the only supported system to run bootstrap builds,
anyway)
* The Python recipe in haikuports.cross is known to not build on
Debian/Ubuntu, but work fine on OpenSuse. There is a patch available in
haikuports bugtracker to allow the reverse.
* You need to populate the haikuports repo package list with some
packages (which don't exist yet) to make the build system happy. But our
git hook to generate the repositories is preventnig me to share this
hack.

Once built, the image currently crashes early in the kernel execution.
On to debug that!
shortcut_catcher: tiny style fix
Add a small helper script to configure gdb

This is useful for debugging the ARM port with qemu gdb stub.
Load uImage higher so it doesn't overwrite itself

Loading of haiku_loader from an uImage is a 2-step process:

* First, the uImage is loaded (in our case from SD card using fatload)
to RAM at a temporary address.
* Then (using bootm), it is unpacked. The uImage is a container format
and can hold several files, with a load and execution address. The files
are copied from the uImage to their final location, and it's better if
that doesn't overlap with the uImage content

When this loading is done, bootm jumps to the entry point found in the
uImage.

We now actually execute our code from haiku_loader. This crashes with
the following call stack:
* vsnprintf
* dprintf
* boot_arch_cpu_init
* cpu_init

It seems vsnprintf is trying to use VFP instructions (probably from the
libgcc) but that triggers some kind of fault, and the handler (setup by
uboot?) ends up crashing the system by jumping to unmapped memory at 0.
Let the bootloader know about ARMv7.

When an ARMv7 CPU is detected, immediately turn on the FPU. This allows
us to use vsnprintf in the TRACE call in that function, as our libc is
compiled with floating point support and will trigger a fault if the FPU
is not available.

This lets the boot go further, and crash in mmu_init. Next steps:
* Find why mmu_init is crashing
* Setup some fault handlers, otherwise we call uboot ones, and they are
not very helpful. They will also probably not work once the mmu is
enabledvery helpful. They will also probably not work once the mmu is
enabledvery helpful. They will also probably not work once the mmu is
enabled...
Style fixes to IK, focus on docs
IK documentation update

* Add \since directive to each method.
* Add documentation for BScrollBar and BScrollView classes.
* Title Case group titles.
* Some other minor documentation updates.
build system: Replace tab wtih space
build system: Add SoundRecorder to Deskbar

... in the "regular" image definition. Fixes #10932
Update translations from Pootle
openjdk: add x86 secondary architecture package for x86_gcc2
Tracker: fix accidental logic inversion. Fixes #10940.
Tracker: Style fixes to DeskWindow
Tracker: Use BPathFinder to find add-ons
BOptionPopUp: check for non-NULL Message(). Fixes #10733

Signed-off-by: John Scipione <jscipione@gmail.com>
Tracker: code simplication to hrev47374

We don't need to create a BNode from a BDirectory because BDirectory derives
from BNode! So use the BDirectory we already have as a BNode and get the
node_ref from it so we can pass it into WatchNode().

Sorry for the noise.
Apply fix suggested by Ingo

* Fix mixup of HAIKU_IMAGE vs HAIKU_IMAGE_NAME
* Use $(1) and $(2) instead of $(<) and $(>)
* Remove useless count parameter to dd
Debugger: Add/handle new suspend state for jobs.

- In addition to waiting for one or more dependent jobs to complete,
a job can now potentially wait for user input to proceed further. Add
a corresponding job_wait_status and respective handling in Worker.
Debugger: Add classes for representing image loading state.

Adds a hierarchy of classes for preserving the loading state information for
a LoadImageDebugInfoJob. These include:
	- ImageDebugInfoLoadingState:
		Top level class that simply stores a reference for  the specific info
		state that we're currently attempting to load.

	- SpecificImageDebugInfoLoadingState:
		Abstract base class representing state information specific to a
		particular kind of debug information.

	- DwarfImageDebugInfoLoadingState:
		Implementation of the above for the case of DWARF.

	- DwarfFileLoadingState:
		Encapsulates the in-progress loading state of a DWARF file for the case
		where a file's debug information is referenced externally, but cannot
		be found.