Eliminate weak symbols from rump kernel syscall handlers, part 1:

Initialize all non-modular syscalls to enosys and expect them to be
filled at boottime.  Do not create the now-unnecessary weak aliases.

Modular syscalls work as before.
Eliminate weak symbols from rump kernel syscall handlers, part 2:

Generate a file (rump.sysmap) which can be used to autogenerate the
syscall loaders.  The file contains syscall handler names and numbers.

Also store "libc" side syscall names in rump.sysmap to help with
the rumprun build process.
Eliminate weak symbols from rump kernel syscall handlers, part 3:

Add a tool to autogenerate callbacks from components to establish system
call handlers for non-modular syscalls.
Eliminate weak symbols from rump kernel syscall handlers, part 4:

Do not query system call handlers by using the rumpuser_dl_globalsym()
hypercall -- it will not work in environments which are not in control
of their own symbols (e.g. rumpuser-xen).  Instead, provide
rump_syscall_boot_establish(), which component constructors can use
to establish their non-modular syscalls.
Eliminate weak symbols from rump kernel syscall handlers, part 5:

regen syscalls to eliminate weak aliases and link-time initialization
Eliminate weak symbols from rump kernel syscall handlers, part 6:

Generate component constructors which establish non-modular syscalls.
Eliminate weak symbols from rump kernel syscall handlers, part 7:

Build component constructors which establish syscalls at boottime.
weak alias removal implication: rumpuser_dl_globalsym() can now sleep
with the fishes.
Remove LD_DYNAMIC_WEAK whine, by large it's not necessary anymore.
When dealing with the PMR register, only use non-secure priority values.
unsprinkle const to fix clang build.  mmm, travis ci
regen
We can't use IPL_SERIAL here, since it would mean its the same as IPL_HIGH
which panics the armgic's assertion.

In practice i dont think this will hurt since even the small queues are
relatively big.
Exynos4's MCT doesn't interrupt on the MCT_LTIMER interrupt but on the
IRQ_G0_IRQ and/or the IRQ_MCT_G{0,1,2,3}. The later are not chosen yet since
they are behind the interrupt combiner.

Confirmed that it indeed calls hardclock() at the specified intervals.