[LibOS+Pal] manifest: Remove support for loader.exec and sgx.sigfile

Supporting these options complicates the design of Graphene and loading
logic significantly, providing little useful functionality:
- loader.exec:
    - the main user of it were our tests
    - worked only for the first process spawned inside Graphene, as it
      was a unidirectional manifest->binary mapping, so the child
      process didn't know about the corresponding manifest.
- sgx.sigfile:
    - probably all existing usages of it were completely redundant
    - was resolved relatively to CWD instead of the executable location,
      which made it mostly useless

From now on, the correct location of the files is:
- either place the manifest and sigfile next to the binary, with a
  matching name, or
- create a symlink to the binary in the folder where manifests are
  stored and launch it through this symlink

Examples/python-simple/python.manifest.template

@@ -2,15 +2,6 @@
 #
 # This manifest was prepared and tested on Ubuntu 16.04/18.04 and tested with
 # Python 3.5 and 3.6.
-#
-# Python must be run with the pal_loader:
-#
-# ./pal_loader python.manifest <script>
-
-# The executable to load in Graphene. By default, PYTHONHOME points to the
-# system installation. To run Python from a local installation, specify PYTHONHOME
-# when running `make` in this directory.
-loader.exec = file:$(PYTHONEXEC)
 
 # Graphene environment, including the path of the library OS and the debug
 # option (inline/none).