First step for more general upgrade trampolines.

"upgrade" needs to install a sane vector table before it enters the
upgraded firmware. This part is for generating that vector table.

There are several parameters for the vector table (chip type, vector size,
location of the relocated firmware), some of which are hard to come by outside
of the compiler toolchain, because those informations are only readily
available as C source. So we really want the compiler to do the dirty work.

The source for that is "upgrade-trampolines.S", which is more or less the same
as "bootloader-vectors.S", except that the jump targets are no numbers but
symbol names.

To make the compiler compile it, we need to supply the symbols somehow - the
code behind them does not exist in "upgrade-trampolines.S". But we can feed the
linker with arbitrary symbols in a file by using the "--just-symbols=" linker
option, it will then happily use that symbols to resolve the jumps in our
source, including jump relaxation and offset calculation.

Leaves the question where the symbol file should come from.

There are at least three different cases of what vectors should be written into
the trampoline table:

* app does not use any interrupt and does not have a vector table
  In this case, all the symbols should point to the applications reset vector.
* app has a vector table, we need to relocate
* the bootloader case, where we know where to jump to explicitly.

In addition, there are several cases on the file format we may see,
* elf file with symbols
* elf file without symbols (i.e. stripped)
* hex
* raw

Easiest way to deal with such variation is using some scripting. The output
from the script should look like this:

---8<---
app__init = 0x000017c0;
app__vector_1 = 0x000017c2;
app__vector_2 = 0x000017c2;
app__vector_3 = 0x000017c2;
...
app__vector_126 = 0x000017c2;
app__vector_127 = 0x000017c2;
--->8---

whereby "app__init" is the applications initialization vector and
"app__vector_X" is address of the ISR for interrupt X. All addresses are
absolute.

You must at least supply as many vectors as the chip needs, but you can add
more if you do not know - extra entries are just ignored.

I added scripts for two particular combinations, the bootloader symbols
extracted from an unstripped elf file and symbols extracted for a normal
application from an unstripped elf file.

Getting the same info from a hex- of raw file would be a bit more complicated,
but not much.
Add trampolines to upgrade and use them.

Add a second payload section ".payloadvectors" to upgrade that contains
the trampolines created by the stuff in the previous commit.