The extra_link_args is sadly not intrinsically used
for many parts of the system_info code.

This commit adds the linking properties stored
when using extra_link_args in the openblas section
to bypass any difficulties in the usage of OpenBLAS.

This is especially helpful when linking against external
LAPACK libraries which requires -lgfortran and possibly
-lm for correct linking.

"earch path" => "search path"

The original distutils assumes runtime_library_dirs to
be located in rpath, however, the internal structures assumes
the keyword to be runtime_library_dirs.
For now numpy.distutils handles both equivalently.

The test has been updated to also test the rpath solution.

A simple test (distutils/testing/test_system_info.py)
to check that the options are read in correctly has been added.
This test has a few faults:

A) It does not allow strict library checks as that can be
   _very_ system dependent.
B) It compiles some simple C-programs but does currently not link
   them to a shared library.
C) As such the test does not check that the flags are actually used.

To circumvent this one should:

A) Make a library of the compiled sources.
B) Check that a runtime_library_dirs is working by checking
   with ldd
C) Make a preprocessor flag to check the output of two commands which
   should differ according to the flags in each block

I am not too much into the distutils compiler suite. So I have not
endeavoured on this path.

- The current test shows that the flags are read in by the standard system_info
  object and can thus be considered a "stable" solution.

- Added note of the 1.10 release schedule.

- Corrected the site.cfg.example, added runtime_library_dirs to
  the OpenBLAS example where it seems appropriate.

- Bugfix for the site.cfg.example (the [DEFAULT] block should be
  name [ALL])
  This might have lead to some confusion, but many of the libraries
  are linked explicitly by their own sections, hence it might not have
  been caught.

Added MKL settings for Intel Fortran Composer.
In addition, changed link to ConfigParser documentation.

their presence in site.cfg is only for the benefit of third party
packages using numpy.distutils

Fixes #654 by not fixing it; I don't think NumPy *can* actually fix
the problem as it's a design flaw in Python's multiprocessing. Listed
various alternatives (Python 3.4 forkserver, single-threaded OpenBLAS,
Python threading).

blas_opt and lapack_opt sections are not actually read by the
numpy.distutils.system_info machinery. They are just meta entry points for the
`get_info` public function that in turns introspec the atlas, openblas and mkl
sections.