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.
Add better documentation of op_mat code generation

Mainly, just mark places where we're doing the wrong thing.
Add use of matrix-maps staged in through op_plan

Rather than assuming that the matrix is numbered the same way as the
first op_dat with encounter, instead pull the correct matrix mappings
from the op_plan structure.  This will additionally require work in
the runtime to stage these in properly.
Add op_i
Add field to parallel loop holding op_iteration_space

Set the iteration space up correctly when encountering the parallel
loop.
Add ability to create empty iteration space

Also calls to populate the iteration dimensions when we encounter
them.  This is so we will be able to check the extents of matrix maps
in the parallel loop against the extent of the iteration space.
Store map indices not extents in op_arg_mat definition

Update CUDA code generation in line with this.  Use the extents of the
iteration space (which was created either by an op_iteration_space
call or by the extents of the first op_arg_mat encountered) to
determine the additional iteration dimensions for parallel loops with
op_arg_mats in them.  Use the map-indices in the op_arg_mat objects to
correctly determine the iteration variable to use in indexing the
relevant matrix map.  In addition, correctly support OP_WRITE
semantics on matrices (no need to zero the temporary entry before
calling the kernel).

The code now does the right thing for constructs like the following:

   op_par_loop(kernel, op_iteration_space(set, 2, 4),
               op_arg_mat(mat, op_i(1), map1, op_i(2), map2, OP_INC),
               op_arg_mat(mat2, op_i(2), map2, op_i(1), map1, OP_INC))

This is useful if (for example) one wants to access matrices that are
the transpose of each other.
Don't allow for single-index expressions in op_arg_mat

We only support OP_ALL style semantics for op_mats in parallel loops,
so abort unless the index arguments are either op_i (referring to
something in the explicit iteration space) or OP_ALL.  Furthermore,
require that the extents of the iteration space exactly match the map
dimensions.