feat: add support for Enarx calls

[rvolosatovs]

~[WIP] (heavily).~ ~Opening this PR for @haraldh to be able to progress and to get some feedback on the issues outlined below (also see Rocket chat)~ ~get_attestation and GDB-specific calls were treated as syscalls from userspace~ https://github.com/enarx/sallyport/blob/2eb6ca1aec2e78896b8c49aeaf5eb9f51a3b218d/src/syscall/mod.rs#L295-L300 ~in previous minor version of the crate~ ~Although GDB "mode", at least, in SGX case is entered via an invalid OPCODE~ https://github.com/enarx/enarx/blob/500c0b8feaa267b559227694c469d2b1e3b12388/internal/shim-sgx/src/handler/mod.rs#L103-L121 ~, therefore the current approach should work fine.~ ~The only call, which needs a designated number that does not clash with "normal" syscalls is get_attestation, if I understand correctly, because that call arrives from userspace, is that correct? @haraldh~

~Is there a reason we can't handle the attestation with the same OPCODE trick as GDB and therefore avoiding assigning it a syscall number?~

Added support for Enarx-specific calls, backends are expected to implement e.g. balloon_memory and mem_info by "hooking into" the item iterator via filter_map on host side

~SGX-specific calls will follow shortly~

There's a lot of functionality duplicated from existing calls, we should probably file a tech debt issue to look into things like deduplicating result handling, either via shared types or macros

Closes #106

[haraldh]

Is there a reason we can't handle the attestation with the same OPCODE trick as GDB and therefore avoiding assigning it a syscall number?

No reason for sallyport to not handle get_attestation the same as GDB.

The only thing we need is pub const SYS_ENARX_GETATT: i64 = 0xEA01; so that the shims and userspace agree on the same number.

[haraldh]

That said, sallyport does not have to care about how userspace calls get_attestation ... syscall or not.. it doesn't matter, because it's an enarx specific extension in the shim <-> host communication.