Turns out RescheduleableAlarm.reschedule is so heavy that it's not suitable for hot loops like tween scheduling. We should probably move it to its own thread instead.

(This might cause one-shot events to fall off sync with "non-binary" events but it should be fine since timing critical events like IMU will still be synchronized.)

So far ffsds4 runs under PyPy but with some caveats:

1. New typing features (e.g. Protocols) are not supported in PyPy due to the lower targeted API level (3.7). This can be resolved once they releases a new version that supports API level 3.8 (which should be the actual minimum required version for ffsds4).
2. The performance is really bad, with the DS4Function thread @ 250 FPS using 20% of CPU on not-so-bad-and-still-better-than-most-maker-grade-ARM x86 processor (!) and Sequencer thread running hotter than CPython most of the time. Profiling might be required once 1 is resolved.
3. No PyInstaller support (for obvious reasons). Just live with it I guess.

If 2 can be resolved, maybe it' possible to list PyPy as supported.

Turns out it's way too complicated and slow to do all the high level event emission ourselves. Plus that there's better, more battle-tested event sequencers like evemu, it makes having our own event sequencer an even worse idea.

Maybe we should pivot from making a fully featured gamepad emulator to just a simple event converter for evdev devices. This way it would also make ffsds4 more useful as a gamepad converter which will be more useful to an end-user for example.

Solution: Add profiler support to all threads that may get benefits from profiling.

A workaround would be detecting if the package is a onefile. If it is, add read permission to all files and directories under sys._MEIPASS.

It would be better to unify all animation-related features (from pressing buttons to multi-segmented IMU operations) into a single animation codebase. This could simplify the sequencer codebase and make implementing new commands easier.