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 think that I made the same remark a while ago: the object should be a
data structure that is agnostic of its usage. The thresholding thing is
something that is related to the RPBI, it should not be in the
GrowableSparseArray. The logic behind this is that the code needs to be
understandable bits by bits, and not only after reading and processing
the whole code. Thus the GrowableSparseArray should do nothing more than
be a growable sparse array.