load() function no longer supported in scipy.

No longer only thrown GraphError upon any error, but instead throw
specific exceptions which are more meaninful and are mapped to standard
python exceptions, such as IOError, ValueError and RuntimeError.

Path sampling is done using different bias, and the edge sampling is now
done correctly. There is now only one parameter 'n_iter' which replaces
'min/max_iter' and 'epslon'.

When using undirected graphs, the implicit direction of each edge was
not properly handled, and the correlated case would not work. Now, in
this case, the direction is always checked, and the edge is inverted if
necessary.

This would cause the graph to become directed (when previously
undirected) in some circumstances.

This is a workaround for a behaviour of graphviz which is not well
understood.

The RNG object must be passed by _reference_ not by value, as is the
default! Otherwise the RNG state does not change...

Target degrees were not being sampled correctly from their probability.

Reference counts of newly created arrays must always be incremented, and
not borrowed().

This prints useful library information.

We will rely on sphinx + docstrings instead.

Import numpy and scipy before everything to avoid weird segmentation
faults depending on the order things are imported.

Python types cannot be checked in parallel. This commit forces the
number of threads to be 1 in such case.

This changes degree_selector(). Now all properties should be tested, not
only scalar properties. Later it can be decided which properties are
valid.

random_graph() now uses a modified algorithm for generation of
correlated graphs, which is more efficient. Instead of giving a function
which returns a sample of the correlated target degree, the user must
give a function which will just compute its probability. This
probability will then be used to choose the edges.

This also simplifies the calculation of the coefficient.

This modified several docstrings and introduces a quick-start guide.

The generators from boost::random seem to have a bug which causes them
to be biased. The generators from tr1::random seem to be in better
shape.

See: http://thread.gmane.org/gmane.comp.lib.boost.user/48006