A self-looping program (a bare `while True:` game loop) never returns to
the top level, which broke two assumptions of the port:

- Stopping meant tearing the whole instance down. Expose interrupt()
  (mp_sched_keyboard_interrupt) so a host can raise KeyboardInterrupt and
  stop a running script in place, then reuse the live instance.
  mp_js_sleep_ms() now slices the sleep and handles pending exceptions
  between slices, so time.sleep() is promptly interruptible too.
- Under MICROPY_GC_SPLIT_HEAP_AUTO, gc_collect() defers collection to the
  top level, which a forever-loop never reaches, so the heap grew
  unbounded to the wasm ceiling. Collect mid-execution from the VM yield
  hook instead. Asyncify scans the stack + registers; JSPI can't (switched
  stack, no register spill), so it scans the tracked C-stack range with
  bounds captured at the outermost entry. gc_alloc_threshold bounds the
  transient garbage held between collects.

main.c: interrupt / sliced sleep, and the mid-execution collector
(gc_collect_if_pending, gc_collect_cstack, MP_JS_NOTE_CSTACK_TOP, and the
MICROPY_GC_SCAN_REGISTERS / MICROPY_GC_TRACK_CSTACK selection).
api.js: expose interrupt().
variants/asyncify, variants/jspi: enable the auto split heap (and memory
growth) so a looping program is the case the mid-loop collector bounds.
tests/ports/webassembly: async_interrupt, async_restart and async_gc
fixtures for interrupt, in-place restart and bounded GC.

Signed-off-by: Phil Howard <[email protected]>

A browser can't open raw sockets, so the socket-based `requests` /
`urllib.urequest` from micropython-lib don't work in this port. Add a
small `_jsfetch` module that does HTTP(S) via the browser's fetch(), for
Python code (or a higher-level pure-Python client) to build on.

_jsfetch.request() kicks off the fetch then suspends the WASM stack (via
emscripten_sleep) until it settles, giving Python an ordinary blocking
call, so it needs a suspend-capable build. It is gated on
MICROPY_PY_JSFETCH and enabled by the asyncify and jspi variants.

jsfetch/jsfetch.c: the `_jsfetch` C module (request()).
jsfetch/jsfetch.js: the fetch() half, as an emscripten --js-library.
jsfetch/jsfetch.mk: build fragment; include it from a suspend build.
mpconfigport.h: MICROPY_PY_JSFETCH gate (default off).
variants/asyncify, variants/jspi: include jsfetch/jsfetch.mk.
tests/ports/webassembly/async_jsfetch.mjs: cover a blocking GET against a
local server.

Signed-off-by: Phil Howard <[email protected]>

Asyncify instruments every function that could be on the stack at a
suspend. For MicroPython that is almost the whole runtime: indirect calls
(the NLR jump callbacks and the print/type-slot vtables) are
conservatively assumed to reach a suspend, so even float boxing in a hot
loop is instrumented (ASYNCIFY_ADVISE reported ~3200 functions).

Add an asyncify-fast variant that turns on ASYNCIFY_IGNORE_INDIRECT and
re-adds just the indirect-dispatch sites that genuinely sit above a
suspend (the VM call machinery + protocol slots, in asyncify_add.txt);
ASYNCIFY_ADD re-roots the analysis so their direct callers are picked up
automatically. It also needs the Wasm longjmp backend, as MicroPython's
NLR wraps execution in setjmp and the emscripten invoke_* trampolines
abort once indirect auto-detection is off.

The result runs the arithmetic / alloc / object-op hot path
uninstrumented - about 2.5x faster, and 31% smaller wasm here.

EXPERIMENTAL: the ADD list must stay complete - a suspend reachable
through an un-listed indirect call would corrupt the unwind silently.

variants/asyncify-fast: reuse the asyncify variant, add the instrumentation
flags and the Wasm exception/longjmp backend.
asyncify_add.txt: the curated dispatch-site list.
tests/ports/webassembly/asyncify_fast.mjs: force a suspend through every
dispatch path and cross-check a checksum against the full build.
tools/ci.sh: build the asyncify-fast variant and run its fixture.

Signed-off-by: Phil Howard <[email protected]>

There is no native code emitter on wasm (MICROPY_EMIT_NATIVE == 0), so
@micropython.native was a SyntaxError. Native code has identical Python
semantics to bytecode - only faster - so allow a port to compile it as
bytecode instead: code written for hardware that decorates hot functions
with @Native then runs unchanged (just not accelerated).
@micropython.viper is deliberately left erroring, as its semantics differ.

This adds the mechanism only, as an opt-in that defaults off
(MICROPY_NATIVE_NOOP). No variant here enables it, so the default builds
are unchanged and native/viper feature detection is unaffected; a consumer
enables it in its own variant.

py/mpconfig.h: add the MICROPY_NATIVE_NOOP option (default off).
py/compile.c: when it is enabled and there is no native emitter, map
@micropython.native to MP_EMIT_OPT_BYTECODE in compile_built_in_decorator.

Signed-off-by: Phil Howard <[email protected]>