Unify matrix assembly+solve in backends (#179)

The storage of matrix data, and the operations on matrices (i.e. matrix assembly and matrix solution), have not been implemented in a consistent manner.

The main problem was that matrix assembly was managed by a `matrix_assembler` type provided by the back end, which had views on information that it required to perform assembly. Specifically, the views were on properties like `face_conductance`, model state like `voltage` and `current`, and on the underlying matrix storage `d`, `u` and `p`.

This was not a good solution because 
  * there was a hidden dependence of the assembly on model data. e.g. if the voltage storage was reallocated, the reference in the `matrix_assembler` would become stale.
  * if we want back end specific optimizations that require a different data layout to that used elsewhere in the back end, this layout should be shared with the solver, but there is no obvious mechanism for doing that.

This patch addresses this by making a `matrix_state` type in the back end.
  * stores the matrix state opaquely, allowing back-end specific optimizations
  * provides interface for performing operations on the state, namely `assemble`, `solve` and `get_solution`.
  * stores fields such as `face_conductance` and `cv_capacitance` that were stored in the `fvm_multicell`, despite being used only in matrix assembly.
  * takes `voltage` and `current` as parameters to the `assemble` interface, removing the hidden reference to model state.

The actual data layout has not been changed in this PR. Instead, the interface has been refactored and hidden references removed so that it is now possible to implement back-end specific optimizations cleanly.