Add frontend translator stubs for op_sparsity and op_mat types
Add op_arg_mat symbol
Add more compiler symbols for OP_MATs
Add storage of op_arg_mat in ParallelLoop

This only changes the way you have to loop over the entries in the
parallel loop if there are op_arg_mats in the calls.

Effectively you now do:

for (i = 1; i <= parallelLoop->getNumberOfArgumentGroups (); i++ ) {
    if (isOpMatArg (i)) {
        do_stuff_for_op_mat ();
    } else {
        do_stuff_for_op_dat ();
    }
}

To get map the global argument number i onto the correct op_dat or
op_mat arg do parallelLoop->getOpDatArgNum (i) or
parallelLoop->getOpMatArgNum (i) as appropriate.
Recognise op_arg_mat call in op_par_loop

This just sets the appropriate flags in the parallelLoop data
structures.
Ignore op_arg_mat calls in OpenMP and OpenCL code generation

Rather than just looping over getNumberOfOpDatArgumentGroups (), we
loop over getNumberOfArgumentGroups ().  But if we encounter an
op_arg_mat, just ignore it for now by continuing the loop and doing
nothing.
Recognise op_arg_mat calls in CUDA code generation

Notice op_mat arguments and generate calls to the kernel including the
relevant data pointers: the matrix data, the row
pointer and the column pointer (we assume for now that we have a CSR
matrix).  In the device kernel, the user kernel is called with the
address of a temporary variable that describes a single matrix entry.
The global offset into the CSR data storage is found and we add the
entry atomically into the data.  If element traversal is carried out
in colour order, the atomic operation need not be included.

Currently missing:

 - the thread loop is wrong: we need to loop over the two dofs in the
   local matrix

 - finding the offset needs to look at the matrix entry row and column
   values
Add storage classes for op_sparsity, op_mat and op_arg_mat
Forward declarations of op_mat types in IC format
Parse op_decl_sparsity, op_decl_mat and op_arg_mat

Deal with declarations of op_sparsity and op_mat types (Imperial- and
Oxford-style definitions).  Also correctly construct data storage for
op_arg_mat calls in op_par_loop constructs.
Generate CUDA code for global matrix assembly

This is currently incomplete in the following ways:

- The code assumes that the mapping array for the op_mat is that of
  the first op_dat (and is the same for both rows and columns of the
  local matrix).  Instead, we should pull the maps out of the
  op_arg_mat and stage them in appropriately (if necessary).

- op_iteration_space style loops are not dealt with, currently the
  kernel is assumed to assemble a single element. i.e. the loop over
  quadrature points is in the kernel, but the loop over the rows and
  columns of the local matrix are flattened into the element loop.
Fix op_dat numbering bug in indirect case
Embryonic support for op_iteration_space

Recognise op_iteration_space constructs in parallel loops and
correctly populate sub-iteration-space extents in op_arg_mat calls
that match with them.  The magic symbol op_i(n) in the index position
of an op_arg_mat means that the upper extent of the loop over map
dimensions should be taken from the nth argument of the
op_iteration_space construct, the lower extent is always taken to be
0.

So for example:

  op_par_loop(..., op_iteration_space(set, 3, 4),
              op_arg_mat(mat, op_i(1), map, op_i(2), map, ...))

produces code where as well as an iteration over the elements of the
set, the kernel is executed with extra arguments i and j where i runs
from 0 to 2 and j from 0 to 3.