capdl-loader-app: Refactor two-phase build design

[kent-mcleod]

The capdl-loader-app has previously used a non-conventional CMake pattern for building. As the app is built with the capDL spec and ELF files for any program data the loader is required to load, the actual CMake target definitions are deferred until the targets for generating the capDL spec are known as well as the ELF targets. These are then used to declare a capdl-loader-app target.

Instead this change uses a different approach:

• It compiles and links the program code leaving the symbols for the capDL spec and CPIO archive containing the ELF files unresolved, while still producing a base object file "capdl-loader.o".
• Later on, a complete image can be created by taking the CapDL C spec and an object file containing a CPIO archive of ELF files and compiling these with the "capdl-loader.o" file. This compilation can be done outside of a CMake build as only access to libsel4 and capdl-loader-app header files are required to compile the CapDL C spec.
• The helpers.cmake file that declares BuildCapDLApplication now builds the rootimage from within a custom command that performs the external call to a compiler with the required include paths and input files.
• the sel4runtime dependency is removed as the loader app doesn't require thread-local storage and basic entry point assembly code is provided by "entry.h" which sets up a stack and then directly calls main() as the kernel places the bootinfo pointer in the first argument register and this is all the capdl-loader program needs to bootstrap.
• As there is only one thread in the loader app, use global allocation instead of thread-local allocation for thread variables such as the pointer for the seL4 IPC buffer used by libsel4.