Correct typos

[nomakewan]

This corrects several typographical errors as well as an incorrect URL in README.md leading to the $50 contest details.

[SpenceKonde]

Looks like we were both working on the same files at the same time x_x

[nomakewan]

No worries. I'm out of the lab at the moment but as soon as I get back I'll resolve the conflicts.

[nomakewan]

Okay, this should do it.

Fixed a ton of errors in the PWMTest example so that it will actually compile, and added it to the list of examples to check against for pushes/PRs. While I did test it on DB just to make sure it compiles and flashes, I did not test on-hardware to make sure that the program actually did what it purports to do. My lab setup isn't really configured for that sort of thing at the moment.

[SpenceKonde]

Thanks

I just can't seem to make even the slightest change to code without fucking up the semicolons and braces can I....

The code was 100% working before I renamed the file and cleaned up the comments, and apparently trashed numerous other parts of the file.

It's of dubious value as a compile test - I don't know it can access any code code paths not otherwise tested. What it will do on hardware is test that PWM comes out of all the pins it's supposed to, tel you how many cycles it saw in a second, and treat anything outside of our guidelines as a failure (480-1920 or something like that - below that andvisible flicker and technicholor trails result if you pwm LEDs, above that and you may need to use a MOSFET driver to PWM a MOSFET gate), it will work if you set TCAROUTEA or TCDROUTEA at the top of setup (TCD mux only avail if you are on a DD, TCD portmux is errata'ed on DB/DA), and that PWM stops coming out when we turn it off, and that the DAC turns on and off. After testing the TCAs, it calls takeOverTCA0, takeOverTCA1 because some of the TCB pins are underneath the TCA pins. and then reenables the timers with the same CTRLA as it had before, so that the TCBs will have a clock to use (but by calling the takeover, the core no longer intercepts analogWrite pointed at that timer, so the logic falls through tothe next rung in analogWrite where it checks for other timers on the pin. It would be an awesome test if I had automatic testing on hardware. Most importantly - it does not require any hardware connections except for the serial port, and UPDI (unless using optiboot)