Use NumPy arrays in the Python bindings

Replace the SWIG array typemaps with ones from NumPy's numpy.i file.
This has been modified to support output of 2D Fortran arrays and to use
a tuple for output of multiple parameters.
Input arrays are also now declared as const.
In order to work with the the NumPy typemaps, the C bindings have been
changed so that arrays of a known size, eg. see
"CMISSAnalyticAnalysisRmsErrorGetNode" for example use the square
bracket array syntax rather than pointer syntax.

This change requires NumPy when using the OpenCMISS Python bindings and
the NumPy header files in order to compile the Python bindings.

This will allow us to provide a "view" on data that has been allocated
within the library, eg. CMISSField_ParameterSetDataGet can be supported,
although this hasn't been implemented yet.

Tracker item 2147.
Support output of pointers to arrays in Python

- This allows Python to access data allocated internally by OpenCMISS, for
  example in CMISSField_ParameterSetDataGet.
- Pointers to arrays with intent INOUT are not yet supported, eg. for
  CMISSField_ParameterSetDataRestore. This will require having input and
  output sizes in the C bindings.
- I had to fix the intent for the CMISSField_ParameterSetDataGet and
  CMISSField_ParameterSetDataRestore routines as these were wrong.
- I also did some small reorganising when setting SWIG typemaps to remove
  some "if, elif, elif..." statements.

Tracker item 2147
Fix matrix ordering in Python bindings with NumPy

- Setting the Fortran flag doesn't seem to work as expected, I have to
  create the array with Fortran ordering from the start.
- There was also an error in the original numpy.i file with IN_FARRAY2
  when the size parameters are first. to_array_contiguous was used
  rather than to_array_fortran, and it appears that require_fortran
  doesn't actually work?
- Accidentally had added the APPEND_TO_RESULT macro twice so I've
  deleted one copy.

Tracker item 2147.
Support pointer arguments with intent INOUT from C

Tracker item 2147.
Support array pointers with intent INOUT in Python

Added a SWIG typemap for 1D array parameters passed by pointer with
intent INOUT. Required for CMISSField_ParameterSetDataRestore.
These require a NumPy array as an input with the correct
data type and dimensions. The array data pointer and size are modified
on output.

Tracker item 2147.
Add redirection for Python field routines

Allow calling the generic interface method when there are different
methods for different data types, eg. Field.ComponentValuesInitialise
can be called and will check the field variable data type, then call
ComponentValuesInitialiseDP or ComponentValuesInitialiseIntg etc.

Unfortunately I don't think it's possible to automate this in a general
way as we want to choose the routine based on the actual field data
type, not the type of input parameter. For example, if we have a field
with DP data type and we call the initialise routine with an integer
from Python, we still want it to call the InitialiseDP routine and cast
the Python integer to a double.

This means that this file will have to be manually updated as required.

Tracker item 2147.
Add public distributed matrix/vector routines

These allow people to get access to matrix and vector data. For sparse
matrices the row and column indices can also be obtained.
Add routines for obtaining solver/equations matrices and vectors
Add method to create a SciPy sparse matrix from a distributed matrix

This will also reshape matrix data for full matrices (from 1D matrix
data to a 2D matrix).

Tracker item 2147
Fix getting sparse matrix data from PETSc

- Fixed MatGetArrayF90 in cmiss_petsc.f90 to use a 2D array argument.

- In distributed_matrix_data_get, cast the result to a 1D array with the
  correct dimensions.

PETSc's Fortran bindings have an error where they return a 2D array even
for sparse matrices from MatGetArrayF90. This meant that when treating
this as a 1D array we only got the first m non-zero values and when
using the C and Python bindings we got a segfault when using C_LOC.

There was some discussion about this on the PETSc mailing list but
nothing was done about it, leaving no way to properly get the matrix
data for a sparse matrix from Fortran:
http://lists.mcs.anl.gov/pipermail/petsc-users/2009-June/004682.html
http://lists.mcs.anl.gov/pipermail/petsc-users/2009-July/004687.html
Add "distributed" to name of public matrix/vector types

We might eventually want to expose non-distributed matrices and vectors
so it's best to call these distributed matrices and vectors.
Update matrix and vector getting routines

- Add a routine to get the solver equations Jacobian matrix.

- Add equations set residual vector and source vector get routines.

- For equations sets, Change NonlinearMatrixGet to JacobianMatrixGet and
  NumberOfNonlinearMatricesGet to NumberOfJacobianMatricesGet.

- Add routines for getting the dynamic matrix type for an equations set
  dynamic matrix (eg. stiffness, damping, mass).

- Also add a routine for getting the dynamic matrix by type rather than
  using the dynamic matrix index.
Fix code style in vector/matrix get routines
Un-comment names in END INTERFACE for distributed matrices/vectors

Comment from Chris about this:

  Originally the Fortran standard had an anomaly in that the end
  interface statement could not be named. The older code thus had
  commented names. This anomaly was fixed in subsequent Fortran
  standards and so we should now use non-commented names.
Allow for multiple residual vectors in future

- Use the field variable type to identify Jacobian matrices for a
  residual vector.
- Add a residualIndex argument when getting a residual vector or
  Jacobian matrix for an equations set. Currently this can only be one
  as multiple residual vectors are not yet implemented.
Use Equations rather than EquationsSet to get matrices and vectors

This keeps the equations matrix/vector get routines consistent with the
solver equations matrix/vector get routines, and just makes more sense.

Also fixed/tidied some doxygen comments.
Add routines for getting equations residual variables

- Add a routine for getting the number of field variables that
  contribute to a residual vector
- Add a routine for getting these field variables
Merge pull request #118 from adamreeve/python

Use NumPy for Python bindings