Depend on the LD scripts.
Move assorted target binaries to example/...
Support for the not-so-tiny 16k devices and a fix.

The fix part:
.............

This is another bootloader-is-no-longer-aligned problem. The result was that
the tiny table was never written. (Ouch again)

The 16k part:
.............

There are currently two tinys with 16k flash, the '167 and the '1634. While
those chips have some CPU features also found on some smaller ATMegas, they
still do not have the separate bootloader  vector table, hence they are a
target for micronucleus.

The main difference to the other tiny chips is, that the 1-word "rjmp"
instruction can no longer reach the entire program memory. As a consequence,
the 16k models support the 2-word "jmp" instruction and also each interrupt
vector now has 2 words, so that an ISR can be located anywhere in flash.

This commit adds support for such devices.

The functional changes are mainly "writeWordToPageBuffer()",
"usbFunctionWrite()" and "rjmp2addr()", but the tiny table is also a bit larger
(10 instead of 6 bytes).

* rjmp2addr

With the 8k devices, all address arithmetic is modulo 8k and we can simply
disregard the highest nibble in the address. On the larger devices, stuff gets
more complicated and we must handle the fact that the "rjmp" offset instruction
is actually a 12 bit signed integer.

There are now two different implementations for 8k and 16k devices. Defining
them as a inline function on the 8k devices did not increase code size.

* tiny table:

The applications reset- and vUSB-vectors may be located anywhere in flash, thus
the according vector fields in the tiny table needs to be 2 words long. To
spare lengthy calculations, we always write absolute jumps into the table. This
may cost 1 cycle extra interrupt latency for the vUSB interrupt.

* "usbFunctionWrite()"

GCC/LD always prefer the shorter and quicker "rjmp"s over "jmp" when possible.
Thus we may see either in the interrupt vector table, we have to guess which
variant is used.

Fortunately, there seem to be only two cases: GCC writes "0x0000" into th
second word and the upgrade firmware leaves a "0xFFFF" behind.

* "writeWordToPageBuffer()"

Here we would need to account for the doubled vector size again. But there are
shortcuts.

If we assume the bootloader to be located in the last 4k of the flash, the code
to manipulate the interrupt vector table is just the same as for 8k devices.

For the tiny table, we can not do much. We still have to write the two more
words to the table.

Summary
.......

All these changes increase the code size quite a bit. Most of the changed
operations deal with 16-bit items, which is not particularly cheap on the AVRs.
Compared to the '861 configuration, the code for the '167 is 136 bytes larger,
and only a small part of this increase is is because of high/low register
address differences (18 or so).

One could argue, that size is not that much of a problem with 16k, and for
configurations with a crystal, the size is still below 2k.