Extension to multiple fields about gridap.jl

[fverdugo]

In commit 4a77258 I have introduced a first multi field driver. However, much of refactoring needs to be done:

Thinks to change in the public API:

• Smarter way of defining bilinear and linear forms. When solving this, one also wants to solve the fact that up to now we have to use varinner instead of inner (both in single-field and multi-field drivers)
• Do not expose the name LinearMultiFESolver (related with the changes to be done in the backend)

In the back-end:

• For the moment, a lot of code duplication is taking place between FEOperators and MultiFEOperatorsmodules. In order to solve this, we have to introduce some extra abstract types that serve as umbrella of the single field types (FESpace,FEFunction, ...) and the multi-field ones (MultiFESpace, MultiFEFunction). Then FEOperator and FESolver should be written in tems of the umbrella types, avoiding code duplicaiton. The umbrella types can be named, e.g., (FESpaceLike,FEFunctionLike, ...) as I have seen in some julia packages. The other option, would be to delete single field types and consider only multi-field ones as single field is a degenerated case. However, I would not follow this approach at all. Multi-field types are only very simple wrappers around the single field ones. The complex part is in the single field types, and I don't want to increase the complexity of this (already complex) code exposing the fact that we have several fields. I prefer to grow the code layer by layer and keep things as separated as possible.

[fverdugo]

The tasks above have been accomplished in commit 3c71346

However, we have not adopted the option of introducing the umbrella types commented above. This does not work since we don't have multiple inheritance. (FEFunction already inherits from IterCellField). To circumvent, this we have used duck typing for implementing FEOpertors and FESolvers in a generic way.

[fverdugo]

With commit 9ebdf55, Gridap supports (volume-coupled) multi field problems both linear and non-linear.

Enhancements can be done in the underlying implementation, but the public API is not likely to change.

Enhancements can be done in other issues labeled as enhancement.

Closing issue.