Additional notes on exploring non-conforming meshes

* Move inner constructor of `GridapDistributed.GenericDistributedModel` as outer constructor. One may need to pass the full set of d-dimensional gids from an existing `GenericDistributedModel` instance to the inner constructor.
* I am positive that `refine(::OctreeDistributedDiscreteModel, args...)` should return an `OctreeDistributedDiscreteModel` with a `GenericDiscreteModel` made of local `AdaptiveDiscreteModel`. At present, this is not the case for some of the variants of `refine`, and thus, among others, we need to do the following in `GridapSolvers.jl`: https://github.com/gridap/GridapSolvers.jl/blob/47955a82d55958cc0585780325c005db3755efe2/src/MultilevelTools/ModelHierarchies.jl#L200, that can be definitely avoided. Besides, we also want the user to be able to transfer functions among FE meshes outside the model hierarchy subsytems, thus needing this feature.
* After porting GridapP4est.jl to PArrays v0.3, I have needed to add `MPIVectorVoid` type and `i_am_in` function. In regards to the latter function, shouldn't it go to PArrays? **UPDATE: [They already went to GridapDistributed]**
* If I execute `rdmodel,glue=refine(dmodel,ref_coarse_flags);
` twice, then Gridap generates an error the second time. The cause of the error is that we are trying to create the `hanging` tag in the face labeling associated to `dmodel`, but this does not make sense as `refine` should not modify `dmodel`. **[Solved in cf93940ddba64c5fc675dccfedc82cfe74052611]**
* https://github.com/gridap/Gridap.jl/pull/921
* `GridapDistributed` does not export `redistribute`. Why not?
* When to use `setup_non_conforming_distributed_discrete_model` versus `setup_distributed_discrete_model` ?
* I am positive that the contents of https://github.com/gridap/GridapP4est.jl/blob/eff06a337e2f1b95d62c3d1fcbbde24dc6d2b670/src/FESpaces.jl should be moved to `GridapDistributed.jl`. However, the issue, as we have with `RedistributeGlue`, is that we would have to create a mock `NonconformingGlue`. Seems feasible though. **[DONE]** in GridapDistributed.
* I have ported `RedistributeTools.jl` from `GridapSolvers.jl` to PArrays v0.3 and put it **temporarily** into `GridapP4est.jl`. Thus, PLEASE, when porting `GridapSolvers.jl` to PArrays v0.3 let us start from here. On the other hand, I am positive that the contents of `RedistributeTools.jl` should go to `GridapDistributed.jl`. We will also need mock tests, though. **[DONE]** in GridapDistributed.
* TO-THINK: better strategy to deal with "orphan" hanging dofs on ghost cells. See, e.g.,:
https://github.com/gridap/GridapP4est.jl/blob/c7d476235370d70617ef4ae23db03435254d1fe8/src/FESpaces.jl#L56 or https://github.com/gridap/GridapP4est.jl/blob/c7d476235370d70617ef4ae23db03435254d1fe8/src/FESpaces.jl#L72
* TO-THINK: a better/cleaner alternative to the `get_cell_dof_ids_inner_space` function https://github.com/gridap/GridapP4est.jl/blob/c7d476235370d70617ef4ae23db03435254d1fe8/src/RedistributeTools.jl#L228. Also to think how the problem that this approach solves can impact other scenarios.
* Mods to `AdaptivityGlue` required to support mixedRefinement will go to corresponding Gridap branch. **[DONE]**
* [TO-INVESTIGATE] New quadrants created by p4est as by-product of the refeniment process have `quadrant.p.user_data == C_NULL` and they should NOT accordingly to p4est documentation and also the tests of `P4est_wrapper.jl` that I run, which look correct. So far I am using a workaround to bypass this problem. See https://github.com/gridap/GridapP4est.jl/blob/b87d15a85c3722b1850ca738c67af6365d083783/src/OctreeDistributedDiscreteModels.jl#L1375 for more details.