TO DO:

• Clean examples
• Add unit tests

This PR adds domain decomposition methods and sub-domain iterators to the gsDomain module.

Sub-domain definition for domains (gsSubDomain, gsTensorSubDomain, gsHSubDomain and gsIndexSubDomain)

The gsTensorSubDomain class is defined with a gsTensorDomain and corners (knot indices) bounding the sub-domain. The domain iterator is optimized to stay in the sub-domain. This class prevents looping over the whole tensor domain and skipping everything outside a specified region (which is sometimes done).
The gsIndexSubDomain class can be used on any domain to create a sub-domain based on a list of element IDs.

NOTE 1: The gsHSubDomain is unused now, but it could serve as an example to renew gsHDomain using gsSubTensorDomain for the leaves.
NOTE 2: There is a gsSubDomain base class, but I am not sure whether we need it.

Decomposition of domains

With the aim to distribute domains over different ranks, the decompose method is implemented. This method provides a gsDomain::Ptr by default, but it (almost always) returns a gsCompositeDomain.
Depending on the type of the domain that is decomposed, the number of pieces to decompose into and the number of elements, we have multiple options:

• A gsSubTensorDomain or gsTensorDomain is decomposed. The decomposition is provided by gsSubTensorDomain and is done by making axis aligned splits, inspired by domain definition of gsHTensorBasis.
• A gsHDomain is decomposed. The domain basically consists of a binary tree and multiple sub-tensor domains. Therefore, the size of each leaf is computed and for each leaf it is estimate into how many pieces it should be decomposed. Pieces are then collected in a gsCompositeDomain.
• A gsCompositeDomain is decomposed. If the number of patches is larger than the number of pieces to decompose into, the patches are distributed according to Karmarkar Karp merging. If the number of patches is smaller than the number of pieces, every patch is decomposed such that it contains close to the average number of elements needed per piece, then the pieces are distributed over subdomains.

Some comments

• We now have gsDomainIterator::id and gsDomainIterator::localId. The id is the ID of the element in the current iterator (e.g. in a sub-domain) and localId is the ID of the element in the parent domain.

NEW:
Domain decomposition via gsDomain::decompose

IMPROVED:
Sub-domain definition and iteration using gsSubDomain

Please consider the following checklist before issuing a pull
request:

• Have you added an explanation of what your changes do and why
  you'd like us to include them?
• Have you documented any new codes using Doxygen comments?
• Have you written new tests or examples for your changes?