Syscall review

[TychoVrahe]

Followup for #4188

We added (most of) syscalls to match the current usage in firmware, but this is not necessarily correct.

Some of them might be too low-level and deserve redesign, these are main candidates:

• storage initialization: probably should be done in kernel, and not exposed to coreapp at all
• sdcard syscalls - maybe we should expose higher level functions instead, so that coreapp doesn't have access to all data on the SD card
• hash processor syscalls - again, maybe we shouldn't expose raw sha256 syscalls, which are needed for firmware header info in coreapp, but perhaps introduce the firmware header info syscall?
• USB syscalls - rethink initializtion, add arguments validation
• display, bitblt - add validation

But we should reconsider more or less each syscall so that we don't expose stuff we don't really need to.

[matejcik]

• hash processor syscalls - again, maybe we shouldn't expose raw sha256 syscalls, which are needed for firmware header info in coreapp, but perhaps introduce the firmware header info syscall?

we also want to be able to accelerate general sha256 usage so if the sha256 syscalls are "secure" in that they don't interfere with one another, we want to keep this

[TychoVrahe]

That is also related to #3638 and also in principle to #4212