Cython subsample

A place to discuss Cython et al. (#210) while making subsample without replacement (the default) faster (issue #208).
**tl;dr** [With great power comes great responsibility](https://xkcd.com/643/). But everything can be solved iteratively, so please leave all your feedback!

---

*Require Cython or not?*
- Always cythonize .pyx files at install time, requiring Cython. It can be implemented by trying to `import Cython` in setup.py and printing an error if it doesn't work. Discouraged by their docs: "It is strongly recommended that you distribute the generated .c files as well as your Cython sources, so that users can install your module without needing to have Cython available." :-1:
- Opt out of cythonization. Same thing, but shipping .c files and falling back to compiling them if Cython isn't available. Also discouraged: "It is also recommended that Cython compilation not be enabled by default in the version you distribute. Even if the user has Cython installed, he/she probably doesn’t want to use it just to install your module. Also, the installed version may not be the same one you used, and may not compile your sources correctly." :-1:
- Opt in. Provide the option to use Cython, but default to building from tested .c files. Implemented here by using an environment variable. Thoughts for a better implementations?

---

*Files kept in git?* Some projects keep the .c files under VC, others don't (@ebolyen and @ElBrogrammer gave some examples). To me, it seems simpler to keep them here simply because I don't know how to include them at release time ;)

---

*Known issues, testing & documentation:* The only part of `subsample` that benefits from Cython is inside an else clause, so the whole PR could be reduced to a private Cython function that implementes that part. However, making it a full module (in the mean time) will allow us to discuss:
- what to do with documentation for modules with an accelerated implementation (we don't want to sync docstrings by hand!)
- show how both implementations could be tested.

---

*Packaging:* Yep, it's importing numpy in setup.py. I'm not aware of a way around this.
Food for thought: It's interesting to note that @ElDeveloper's remark:
> > Isn't this then the same issue we have with numpy and verman?

> It is, but the more I think about it, it's not a problem of the package nor of the dependencies, but of the way that pip works.

is very similar to a remark by Travis Oliphant [here](http://technicaldiscovery.blogspot.com.es/2013/12/why-i-promote-conda.html):
> some [...] simply claim that setup.py files that need numpy.distutils are "broken" because they import numpy before "requiring" them.  To this, I reply that what is actually broken is the design that does not have a delcarative meta-data file that describes dependencies and then a build process that creates the environment needed before running any code to do the actual build. This is what `conda build` does and it works beautifully to create any kind of binary package you want from any list of dependencies you may have