SimultaneousSolutions

We've encountered some situations in our own research lately that benefit substantially from simultaneous solution, e.g.,

would normally be solved with

where the `...` is ideally some `ConvectionTerm`, but which might be an explicit `(DphiT * T.getFaceGrad()).getDivergence()` and so on if w can't easily factor out the dependence of $D_{\phi T} (\phi, T)$ on $\phi$.

It can be advantageous, though, to create a new master variable $\xi$ where $\xi[1,\ldots,N] = \phi[1,\ldots,N]$ and $\xi[N+1,\ldots,2N] = T[1,\ldots,N]$ and to compose a master equation to simultaneously represent both the $\phi$ equation and the $T$ equation.

Daniel presently has a functional (but arguably brutish) implementation of this, but we've been brainstorming a way to make this more general and more elegant. The idea that we are currently playing with is to use the `()` method of a `Term` to change it from a generic operator like it is now into an operator applied to a specific `CellVariable`, i.e. $\nabla\cdot(D \nabla \phi)$ instead of $\nabla\cdot(D \nabla)$.

 * The current syntax will remain valid. `DiffusionTerm(coeff=D)` will continue to represent $\nabla\cdot (D \nabla)$. You must call `solve(var=phi)` or `sweep(var=phi)` to apply the operator to the variable $\phi$.
 * If, instead, you write `DiffusionTerm(coeff=D)(phi)`, this will represent $\nabla\cdot (D \nabla \phi)$. There will be no need to pass a variable to `sweep()` or `solve()`. In fact, it might be an error to do so.

In this new syntax, we would write

and then call `solve()`, either without a `var` argument, or perhaps with a `var` argument that must only contain a tuple of `phi` and `T`. I'm inclined to prohibit the `var` argument, because the list of solution variables is already implicitly determined by the `Term`s, so its value is proscribed.

It should also be possible (and maybe a bit clearer) to write

We had originally talked about writing `eq = eq_phi & eq_T`, but as I write this up, I now don't think there's any reason to introduce this new syntax.

There remains an issue of what to do about boundary conditions.

 * One option is to make boundary conditions also take a `__call__()` method, so `FixedValue(...)` would apply to whatever variable was passed to `eq.solve(var=...)`, but `FixedValue(...)(phi)` would explicitly mean $\phi|_\text{some boundary} = \text{some value}$.
 * Another option is to wait for our planned boundary condition reform and to require all boundary conditions to either be applied directly to `CellVariable`s or to be incorporated as `SourceTerm`s in the equation, as discussed in the new FAQ.

We welcome suggestions of how users would like this to look and behave.