Refactor: abstract SDK interface for `libsgxstep`

[jovanbulck]

Ideally libsgxstep should be less tightly coupled to the Intel SGX-SDK and rely on a clean and stable interface that can be easily ported to other SDKs or libOSs, eg at least the following:

• set AEP by hooking EENTER to allow for custom AEP stub for single-stepping
• get TCS for current enclave to allow to retrieve metadata (eg base address) via the driver. This should be similarly possible by intercepting EENTER
• refactor build system to more easily link libsgxstep to other SDKs

At least the user-space SDK components should be easily pluggable. Integration with the kernel space isgx driver may be more tight, but that should be less of an issue as most SDKs rely on the isgx driver anyway..

[jovanbulck]

some relevant notes on moving fwd here; currently we rely on the following patches (which can probably be further reduced as outlined):

• [ ] sgx_get/set_aep: this is the only crucial part: we must be able to set our custom aep_trampoline.S stub on EENTER-ing the enclave -- current patch does not work with the VDSO eenter provided by newer Linux kernels..
• [ ] sgx_get_tcs: to query TCS address that is saved on first EENTER -- we can probably get rid of this and by saving the TCS in rbx in SGX-Step's aep_trampoline.S

TODO: look into how to best support __vdso_sgx_enter_enclave; maybe we can trick the vdso_detector to take our customized vdso_sgx_enter_enclave function so we wouldn't need any patches in the SGX SDK runtime ^^

Note: Linux VDSO system sets the AEP here

[jovanbulck]

idea to look into: maybe we can simply replace all enclu instructions in VDSO and shared libraries with ud2 and trap these with a users-space signal handler to automatically redirect to our stub without needing to recompile or patch any untrusted runtime..