Micronucleus for other tinys

Hi Jenna,

here a first batch of changes towards broader device support  with micronucleus. These patches include

* support for all F_CPU settings supported by vUSB
  + this includes variations that use a crystal instead of the RC oscillator.
* build system improvements to allow easier integration of new platforms
  + multiple variations can now be build in one go
* upgraded vUSB 
* some code cleanup

I hope I sufficiently documented the changes in the commit messages and/or as comments in the code.

Id like to hear your objections (or blessing) before I go further with merging the 16k device stuff. 

And there are a few more open issues on how to deal with different MCUs in other places

Hardware ID:

The upload utility should be able to verify that the firmware file to upload actually matches the device. Micronucleus did not support anything but the '85, so there was previously no need to report any hardware ID.

The official device ID apparently consists of three bytes, the manufacturer id (0x1e for Atmel), the device memory configuration and finally an ID on the chip generation. We may also want to indicate the hardware variation used for vUSB.

The chips identity can either be retrieved from the chip itself or from some defines provided by avr-libc. The latter is probably more efficient. We also know the hardware configuration used to compile the bootloader (at compile time) and we also know the memory configuration.

Minimum ID info would consist the chip generation plus hardware variation (we can infer the memory configuration from the available memory, which is already reported)

Maximum ID info would consist of the complete 3-byte chip ID plus a byte to indicate the vUSB configuration.

Leaves the question, how to report that.

One way was through the USB device version. The device sets the device version to the running micronucleus version, however, the upload utility does not actually use that (due to a bug, it checks for the USB protocol version which is 1.1) Therefore, it would be save to re-purpose the USB device version to indicate the chip generation + hardware variation. If necessary, the micronucleus version could be provided through the device info request.

Alternatively, the chip ID + hardware variant could be indicated in the device info request.

Both variants would require to amend the device info report. 

Bootloader upgrade firmware:

Obviously, that nifty thing needs some insights on boot loader and the hardware configuration  I would suggest to integrate the stuff in "ugrade/" to "firmware/" so it can easily use the new firmware. 

Ciao
  Andi