Applet sandboxing

This issue tracks the design space for applet sandboxing.

| | Performance | Sandboxing | Portability | Code size | Memory footprint |
| --- | --- | --- | --- | --- | --- |
| WebAssembly | Very slow | Full with validation | Full | 20k to 200k (depends on interpreter) | 2k to 200k (depends on interpreter) |
| Pulley | Rather slow | Full without validation | Compiled for Pulley version | Rather high (but being reduced) | Very high (but being fixed) |
| LFI[^lfi] | Rather fast | Full with verification | Compiled for target architecture | Rather low? | None? |
| Native | Very fast | None | Compiled for target architecture | None | None |
| CHERI | Very fast | Full | Compiled for target architecture | Very low | Rather low (depends on the ratio of pointers to data) |

Note that for target-specific solutions (LFI, Native, and CHERI), we ideally don't want to link with the platform. We want to use a portable function pointer interface which is not designed yet. Currently, Native is linked to the platform and thus even less portable.

Related issues:
- #31
- #46
- #458

[^lfi]: [Lightweight Fault Isolation](https://zyedidia.github.io/papers/lfi_asplos24.pdf)