7.2.x autoreload rework (again)

[dhalbert]

#6132 had a regression: when doing fake deep sleep, a write to CIRCUITPY waited until sleep was done instead of restarting immediately. I fixed this but still saw some flakiness.

After some cogitation, I reworked the basic logic of auto-reload. Instead of using ticks to count down a time before raising the reload exception, I raise the exception immediately, and then wait in main.c for the auto-reload delay, restarting the clock if new writes occur. auto-reload is also check in the fake/real sleep loop in main.c, as before. The new code is a little smaller.

Summary:

• Moved sleep countdown to main.c.
• Lengthened CIRCUITPY_AUTORELOAD_DELAY_MS from 500 ms to 750 ms. At 500 ms I sometimes saw IOErrors or filesystem corruption, especially when using emacs, which writes backup files.
• Interrupt running program immediately on write to CIRCUITPY. This makes the program stop faster, and gives the user immediate feedback which ameliorates the lengthened delay. It's also safer, because the program is not running while the filesystem is changing.
• Renamed supervisor/shared/autoreload.* to supervisor/shared/reload.* because of the next change.
• Moved code in py/reload.* code to supervisor/shared/reload.*
• Changed some function names again, after Make autoreload checking more robust #6132's changes.

Tested on CPX, Feather nRF52840, MagTag, and Feather RP2040.

Basic test program (which I edited repeatedly):

for j in range(10000):
    for i in range(1000):
        pass
    print("doing stuff", j)

Also tested with simulated deep sleep on MagTag and Feather nRF52840.

I'd be happy if others tried this too, to see if fixes #6007 for them.

[jepler]

I raise the exception immediately, and then wait in main.c for the auto-reload delay, restarting the clock if new writes occur.

This sounds good! It will help with a problem I often saw, where a program would stutter just before auto-reload would kick in.

[tannewt]

Nice! I love the simplification.