NF: Randomized Parcellation Based Inference

Tadaaaaam... Implementation of Randomized Parcellation Based Inference [1].

Main accomplished tasks:
* Refactoring: move some functions that were common to permuted OLS and RPBI into a utils.py file.
  orthonormalize_design/matrix, f_score computation, ...
  Tests have been changed accordingly.
* Re-introduce GrowableSparseArrays (and corresponding tests).
  They have already been reviewed in a former PR about permuted OLS before they were finally removed.
  Now, we needed to re-introduce them because we need to address the data efficiently, in different 
  manners and for different purposes.
* Introduce some functions to generate/deal with randomized parcellations.
  They could be moved to a more generic module that serves this purpose (creating multiple
  random parcellations, transforming a dataset with all of the built parcellations)
* Examples: the three examples on massively univariate analysis have been duplicated and RPBI is now
  applied. This is a lot of examples, but they will be structured at some point (see issue #195).
  Issue: examples can take up to 30 minutes on a laptop, using one single CPU (see discussion below).

The code for RPBI is optimized but a run of the algorithm remains costly. This is because RPBI requires the computation of many parcellations (97% of the total execution time). Only 3% of the computation time is spent on the permutations, when 10,000 are performed (which is already kind of a lot, but recommended).
Fortunately, both the computation of the parcellation and the statistical inference part can be parallelized.
Therefore, on a 10-core station, the computation time boils down to less than three minutes, which is acceptable. Still, the examples policy requires that n_jobs=1 by default.

[1] Benoit Da Mota et al. Randomized parcellation based inference, NeuroImage, Volume 89, 1 April 2014.
> I exactly want the opposite behavior: a dummy object that does not DO anything and simply stores maps

Here I do not agree. I think it is up to the object to select the data that it stores. that way it can be "fed" transparently.
Once the threshold has been set up --depending on the type of values we want the GSArray to contain-- there is nothing to do but appending data and merging GSArrays together. That behavior makes the GSArrays usable as black boxes, which is an important feature for a data structure. Would the threshold be the responsibility of the developer, it would separate the theoretical properties of the object (i.e. "it is suppose to contain data above a given threshold") and what happen in practice (i.e. "is it really the case?").

> I especially do not want it to be generic in any sense

Yet I have been asked to name its entries with generic names ("x", "y", "iter") ;-)
(see https://github.com/nilearn/nilearn/pull/157#discussion_r9372040, and one other former comment of yours: _"I think that the ides is that the structure is fed by some iterations of a given estimator, that might be a permuted estimator."_)
For me it is not a matter of genericity, but a matter of modularity.