Debounce keys after stable release

[rschmitt]

Contact bounce can occur when depressing or releasing a key, but the current debounce implementation only handles the former case. The debounce timer begins when a key is pressed, and if a key is held longer than that brief interval, a bounce while releasing the switch would be interpreted as a new key press. This could result in both consecutive (A -> AA) and non-consecutive (AB -> ABA) duplicate keystrokes, depending on vagaries of timing.

This change:

• Tracks debounce state independently for every key.
• Disarms a key when its press is accepted.
• Rearms it only after 20 ms of continuous release.
• Restarts release qualification if the contact closes again.
• Disarms automatic repeat when its key is released, preventing a rejected re-press from inheriting a stale repeat timer.
• Passes the actual keyboard clock frequency through iomapper and keyboard_complex, instead of assuming 50 MHz. (This ensures that key_debounce_milliseconds correctly translates to the intended 20ms and not ~25.)
• Replaces the obsolete asciisimulate test with debouncesimulate.
• Removes an excessively noisy matrix-RAM diagnostic message.

The tests cover consecutive and non-consecutive re-strikes, stale automatic-repeat state, and normal key repeat.

Testing

make debouncesimulate

Tested successfully with both consecutive and intervening-key debounce scenarios. Also tested on real MEGA65 hardware with additional debug logging in order to empirically verify the occurrence and specific timings of contact bounce.

[rschmitt]

I think @dansanderson has done the most recent work on the keyboard, including debounce/repeat issues in particular.