Prevent OpenBLAS from modifying the scheduler affinity

Most of the information is already in the commit:

    Julia already manages the scheduler affinity by itself, which is subsequently
    undone by OpenBLAS pinning to the first core available. Because of this, external
    commands spawned from Julia would be restricted to a single core, which in case of
    multithreaded applications is very suboptimal.

I ran into this by `spawn()`ing a MATLAB session from Julia; it always seemed to be using a single core while running the very same command from a terminal made use of all available ones. Tracing all system calls, it seemed that the main julia process called `sched_setaffinity` multiple times, once from Julia's `init.c` (allowing use of all cores) and another time from OpenBLAS' `driver/others/init.c` (pinning to the first core). The latter seems to be an OpenBLAS optimization, as per http://comments.gmane.org/gmane.comp.lib.openblas.general/128

That thread also mentions the R guys running into the same problem, and proposes using the `NO_AFFINITY` compilation flag to avoid OpenBLAS from touching the affinity. This pull request adds that very build flag to the OpenBLAS Makefile rule, fixing the aforementioned issue with spawning multithreaded programs.