unified vector table initialization

the cortex generic interrupts get moved to lib/cm3/vector.c, the
platorms' individual irq names, initialization and handler prototypes go
to platoform specific irq.h files.

as the vector.c file heavily depends on platoform specific headers, it
can't be built once-and-for-all in lib/cm3/, so there are inclusion
stubs in the various architecture dirs; this might be better solved with
Makefile / include path handling.

one particular file is lib/lpc43xx/vector.c; that platform's
initialization code contains an additional section to copy everything
from flash to ram (which probably performs better there). that code
still resides in the inclusion stub, and gets mashed in using defines.
would need a cleaner implementation together with the Makefile solution.

this commit contains some files of the upcoming efm32 branch, from which
it was cherry-picked.

the .bin files produced from before and after this commit only differ in
lpc43xx, where the startup sequence was subtly modified.
Merge branch 'master' into generalizations

Conflicts:
	lib/lm3s/vector.c -- split out to lm3s/irq.h
	lib/stm32/f4/vector.c -- put the floating point initialization code into a function like in lpc43xx
nvic.h factored out (incomplete)
merge irq and nvic code using a script
dispatch for chip specific nvic
add irq cound to existing nvic.h files
unified nvic.c
fallback for unknown chips
modified examples to use libopencm3/cm3/nvic.h instead of /stm32/
nvic unification

* created include/libopencm3/cm3/nvic.h from the respective stm32 and
  lpc43xx files. the chip specific definitions were left in place (they
  were already split out in sthe stm32 case).
* created lib/cm3/nvic.c from the respective stm32 and lpc43xx files. a
  hack from the lpc43xx was taken over (for manipulating the internal
  interrupts); for now it'll work.
* created a include/libopencm3/dispatch/ directory where the dispatching
  of files with common interfaces but different implenentations can
  happen; for now, an nvic.h there includes the respective irq name
  definitions. (future implementations might have some automation or
  preprocessor magic there; so far, it's manual dispatching based on
  defines.)
* for efm32, an nvic.h gets generated from an interrupt list, the
  rationale for code generation is, in this case, that this can't be
  done easily in c preprocessor, and it's really just a list of
  definitions and not code proper.
* examples now include <libopencm3/cm3/nvic.h> instead of
  <libopencm3/stm32/nvic.h>
drop two-line vector.c dispatchers in favor of central dispatch
switch all interrupt lists to yaml format
split irq.yaml output in nvic.h and vector_nvic.h

the weak pragmas need to be used in the very compilation unit where
their target is defined, requiring another dispatch
integrate irq2nvic_h script in buildprocess
vector.c unification

this makes the previous hackish vector.c assemblies into dispatched files
(using the same mechanism as for nvic, just this time in lib).

the old irq.h files that were generated manually from the old vector.c files
were dropped in the process, as were the nvic.h files, and replaced with very
simple yaml lists that generate the headers.

file generation takes place both in the include/ and the lib/ part, as some of
it is definitely header stuff (the NVIC_name_IRQ defines), and some of it needs
to be included in specific compilation units (the weak pragmas).
fix bug resulting from equally named files

the local vector.o files shadowed the ../cm3/vector.c from VPATH,
resulting in empty reset vectors.
adapt lpc43xx example to generalizations
nvic.h generation script: be on safe side with directories

now tries to mkdir its way to the output files

this wouldn't be a problem currently if it wasn't for the efm32 data
lingering in the wrong branch, but otoh it's just on the safe side in
case we meet architectures that don't need other specializations at all.
BEGIN_DECLS wrap nivc.h declarations for c++
unify scb (system control block)

these register definitions are common to all cortex mcus. some of the
registers might not be implemented everywhere (especially the floating
point registers), but defining them does no harm.

this modification does not result in any changes in the example
binaries.