templates: seL4_IRQControl -> seL4_IRQHandler

These types should be seL4_IRQHandler, and were misnamed as
seL4_IRQControl, which is a different type of capability.

Make error-handler.c a macro

Moves the 'error-handler.c' template logic into a 'helpers' template as a macro with
arguments, instead of a template file that is 'include'd and relies on peeking at
global variables to simulate argument passing.

Fix licenses

Added missing variables needed by error handler

Replaced aep with notification internally

This changes variable names and comments replacing aep with
notification. This change should have no impact on functionality.

Update some deprecated uses of seL4_Notify.

Fix: rename 'aep' to 'notification' in arguments to alloc.

The internals of python-capdl have changed and unfortunately silently accept
the old 'aep' parameter, but then raise a message-less exception. This commit
corrects such calls to `alloc` to correctly allocate a notification object.

Replace usage of seL4_Wait with seL4_Recv to match new API.

Find and replace seL4_AsyncEndpointObject with seL4_NotificationObject.

Always pass a cap to an AEP when associating IRQs.

Prior to this change, templates that associated IRQs with AEPs always did so via
an AEP object. Internally, the python-capdl module would allocate a cap to this
object, as IRQs always need to be associated with AEP *caps*, as opposed to AEP
*objects*. This change modifies all in-tree instances to pass a cap to the AEP.
This is marginally more efficient (due to avoiding creating another cap in
python-capdl, but the main motivation for this change is that an upcoming
change to python-capdl removes the ability to pass an AEP object as this
parameter and requires a cap.

Replaced seL4_Wait with seL4_Recv in .c files (including templates)

Refactored parser init commit.

Replaced calls to seL4_Notify with seL4_Signal

Replaced AsyncEndpoint with Notification. Applied "s/AsyncEndpoint/Notification/g" and "s/aep/notification/g" to each file.

Fix: Include stddef.h and stdint.h where appropriate.

This issue only became apparent after pulling in the change that divorced
libsel4 from libc.

Accept integer literals in any form for attributes.

Optimisation: Use new configuration dictionary interface in the templates.

Templates: Name per-interface error handlers statically.

This allows us to more straightforwardly blacklist these symbols -- which is
also done in this commit -- to avoid them appearing in verification input.

Implement error handling in glue code.

This commit replaces previous assertion placeholders and other assumptions with
a flexible error handling mechanism. For details on how to use this, refer to
the accompanying documentation.

Switch to using libutils unreachable macro.

Change template license headers to Jinja comments.

The effect of this is that they do not appear in generated output, which was a
bit confusing previously.

Closes JIRA CAMKES-319

Conflicts:
camkes/templates/autocorres/AsynchNativeFrom.template.thy
camkes/templates/autocorres/AsynchNativeTo.template.thy
camkes/templates/autocorres/RPCSimpleFrom.template.thy
camkes/templates/autocorres/RPCSimpleTo.template.thy
camkes/templates/autocorres/SharedDataFrom.template.thy
camkes/templates/autocorres/SharedDataTo.template.thy
camkes/templates/echronos/eChronosAsynch-from.template.c
camkes/templates/echronos/eChronosAsynch-to.template.c
camkes/templates/echronos/eChronosDirectCall-from.template.c
camkes/templates/echronos/eChronosDirectCall-to.template.c
camkes/templates/linker.lds
camkes/templates/linux/component.template.c
camkes/templates/linux/component.template.h
camkes/templates/linux/linuxMQ-from.template.c
camkes/templates/linux/linuxMQ-to.template.c
camkes/templates/linux/linuxMQEmpty-from.template.c
camkes/templates/linux/linuxMQEmpty-to.template.c
camkes/templates/linux/linuxMmap-from.template.c
camkes/templates/linux/linuxMmap-to.template.c

Move Jinja macros into Python.

Jinja macros have unexpected, and often unpleasant, behaviour. A non-exhaustive
list of issues with them is:
- They are not first class Python functions so cannot be passed within the
template context to, e.g., `map`;
- They can mask and inadvertently overwrite your local variables;
- Certain types of references have unexpected expansions within the context of
a macro;
- Calling a macro within a macro is dangerous; and
- You cannot call certain Python functions from within a macro.

This commit transliterates the existing macros into Python, attempting to
preserve all current functionality. This has involved essentially inverting
their implementation such that they become C hosted within Python, rather than
Python hosted within C. The macros are now unconditionally available to all
templates (see Context.py).

This change is intended to be transparent to template authors and CAmkES users.

Conflicts:
camkes/templates/echronos/eChronosAsynch-from.template.c
camkes/templates/echronos/eChronosAsynch-to.template.c
camkes/templates/linux/component.template.h
camkes/templates/linux/linuxMQ-from.template.c
camkes/templates/linux/linuxMQ-to.template.c
camkes/templates/linux/linuxMQEmpty-from.template.c
camkes/templates/linux/linuxMQEmpty-to.template.c
camkes/templates/linux/linuxMmap-from.template.c
camkes/templates/linux/linuxMmap-to.template.c
camkes/templates/macros.jinja

Release snapshot