Bring the xmega's timer driver over to TCA0

[theAndreas]

Ports the timer driver from the retired xmega E5 project onto the Dx's type A timer. The
source is theAndreas/XmegaTimer — the finished
version of the driver that lived in Wordclock_xmegaForArduino/ as a torso, where init(),
setPeriod() and read() were implemented and start(), the interrupt and all of the PWM
were declared and never written.

The shape comes across intact: one class, a traits struct choosing the instance, dual-slope
counting with the overflow at BOTTOM, 10-bit duty, and a compare channel checked at compile
time rather than at run time. What differs between an xmega E5 and an AVR128DA48 is the
register layer, not the design.

What could not come across unchanged

The route. TCA0 comes out of reset on PORTA, and PA0 and PA2 are USART0 TXD and XCK going
into the CCL — the strip's pulse widths. A timer enabled on its default route drives both, so
init() sets PORTMUX.TCAROUTEA to PORTB before any channel can reach a pin. PORTD is left
to PowerSwitch.h, PORTC and PORTF are the console and the two-wire bus.

The interrupt level. On the xmega the overflow sat on the PMIC's low level so the core's
millis() could preempt the callback. The Dx has one CPUINT.LVL1VEC where the xmega had two
levels, and WS2812::init() has already given it to USART0_DRE, the handler that keeps bytes
flowing inside the strip's reset gap. Taking it for the timer would corrupt a frame. The
overflow therefore runs at level 0 and the callback is not interruptible — the header says so
rather than leaving it to be discovered.

The period update. setPeriod() writes PERBUF, where the xmega wrote PER outright. In dual-slope mode a TOP that lands below the counter mid-period is not
picked up until the counter has run to 0xFFFF and wrapped — one period of several hundred
milliseconds exactly where a shorter one was asked for. PERBUF is taken over at BOTTOM. This
is the one behavioural fix rather than a translation; the xmega had the same hazard.

The prescaler also gained a step, since the Dx has a 16 between the 8 and the 64. A period that
used to round up to the 64 now keeps four times the resolution.

Measured

in the image as it stands	12 bytes of flash, 0 RAM
linked against a program using the whole API	1761 bytes, +322 with the third commit

The first number is small because nothing calls the driver yet: with no caller, LTO folds the
callback to nullptr and keeps nothing but the empty ISR. The clock's tick is still polled off
millis() in main.cpp, and this does not change that — it is a driver sitting ready, not a
new time base.

Both avr-dx and simulator build clean under -Wall -Wextra, the simulator's test suite
passes, and tools/documented-sizes.py is green (the README's size sample moved 48078 → 48090
with --fix). esp32 and rp2350 are untouched: every backend globs its own platform/
directory, and both new files are under platform/avr-dx/.

Derivative portability

The first commit compiled for the AVR128DA48 and for nothing else, which made it the only file in
this backend that does — the other twelve sources build for an avr128da32 unchanged. The second
commit fixes that.

Two independent mistakes. TimerA1 names TCA1, which is fitted to the 48- and 64-pin parts
alone, and TIMER_USE_TCA1 did not protect it: that switch guarded only the explicit
instantiation in the .cpp, while a traits member body is compiled wherever the header is read.
Both traits now sit behind their own switch. And the route was PORTB, which the 28- and 32-pin
parts do not have — of the four they do have, A, C, D and F, every one is already taken by the
strip, the console, the supply switch and the bus.

The port is therefore named by its letter in TIMER_TCA0_ROUTE_PORT, with the PORT_t and the
PORTMUX group config pasted from it, so the pair cannot disagree. Where no default exists the
header stops at an #error naming the macro.

derivative	result
avr128da48, avr128da64, avr128db48	build clean
avr128da32, avr128da28, avr64dd14, avr32da28	stop at the #error
the same four with -DTIMER_TCA0_ROUTE_PORT=D	build clean
TIMER_USE_TCA1 on, part without TCA1	stops at the second #error
TIMER_USE_TCA1 on, DA48, TCA1 on PORTC	builds clean

One thing worth recording, because it cost a round: the timer name cannot be a macro argument.
TCA0 is itself a macro, an argument is expanded on the way through the paste helper, and
PORTMUX_ pasted onto the opening bracket of (*(TCA_t *) 0x0A00) is where it stops. One route
macro per timer, with the name as plain text in the body, has no such step.

None of this reaches run time: the image is byte for byte what it was.

Review fixes

The third commit fixes what a review of XmegaTimer turned up. All of it came across with the port,
and the same fixes go back to the xmega repository.

• read() divided before it shifted, so the prescaler scaled the truncation up: at 1024 it
  moved in steps of 1024 us where a tick is 43 us. Shifted first, it is good to one tick.
• The duty did not follow the period. It was turned into an absolute compare value once, so
  init(1000), 50 % and then setPeriod(2000) ran at 25 %. The duty is now kept per channel, and
  setPeriod() recomputes the compare buffers next to PERBUF, so both arrive at the same BOTTOM.
• PERBUF for a stopped timer too, because resume() continues mid-period. start() loads
  PER and CMPn directly while the timer is disabled, since otherwise the first period ran on
  CMPn = 0. A forced UPDATE would not do: an UPDATE still pending in CTRLESET, ORed with
  RESTART, reads as RESET.
• Smaller fixes: setPeriod()'s "set to maximum" branch was unreachable, so an out of range period
  (and 0 us) is now refused outright. attachInterrupt() clears a stale overflow flag.
  stop() does nothing before init(). F_CPU has to be a multiple of 2 MHz, which is now asserted.

The image is unchanged at 48090 bytes. The whole API costs 322 bytes of flash more (1290 -> 1612
with Timer.cpp linked standalone) and 8 bytes of RAM.

What is not verified

It has not run on hardware, which puts it exactly where the rest of this backend is — see
the README's Gaps section. The register writes were checked by reading the disassembly instead:

• PORTMUX.TCAROUTEA masked with 0x07 and set to 0x01 (PORTB)
• CTRLB ← WGMODE_DSBOTTOM (0x07)
• CTRLESET ← 0x0C (CMD_RESET) in init(), 0x08 (CMD_RESTART) in start()
• the ISR on vector 7 — TCA0_OVF — clearing OVF in INTFLAGS at 0x0A0B
• start() in the order ENABLE off, PER (0x0A26), CMP0..CMP2, CLKSEL, RESTART,
  ENABLE on; setPeriod() storing PERBUF (0x0A36) and CMP0BUF..CMP2BUF together

What a disassembly cannot show is the one thing a scope would: that the overflow really arrives
at BOTTOM and not at TOP, which is the difference between the period asked for and twice it.

The compile-time channel guard was tested by asking for a fourth channel on a three-channel
timer; it fails with static assertion failed: this timer has no such compare channel.