Correct handling of the -e switch

A regression led to the generation of BOOST_PYTHON code with this flag,
which is incorrect. Improve dic/CLI.rst to document the interface and
add a few extra test cases to prevent such regressions.

Add pythran-config script similar to python-config to help third party
compilation. Pythran-config is preferred over pkg-config because it can
directly call the pythran package, and it is aware of pythranrc.
Add proper error logging for an unlikely situation

The test suite did not capture the situation when an exception was
raised in Python and not in Pythran.
Fix pythran long header when GMP is not used
Add missing headers

The problem only arises when the headers are included directly from C++.
There is currently no test case for this situation, as it is not the
most useful part of Pythran, still writing a pure C++ test suite for
Pythonic would be a great way to deal with this kind of issue!
Add basic SIMD testing

This is *not* to have full coverage, but rather to prevent regression
from what is already supported, as no testing is done otherwise. As a
consequence, some tests are commented in test_simd.py.

Note that this forces the inclusion of a large part of Boost.SIMD, and
thus the tests are running slower, (but only if boost.simd is activated
and numpy is used)
Speedup container conversion

Boost::python extract is actually quite slow, as it performs a lot of
checks. Let's be wild and speedup the process!
Add an extra test case

Works like a charm!
Improve slicing by specializing for step = 1

When step is one, many formulae no longer require a multiply. This
improves a lot the performance of several kernels, for a relatively low
cost.

As a side effect, renamed list_view into sliced_list and str_view into
slcied_str, using the same naming scheme as in ndarray.
Do not make useless copies in tuple constructor
Rework handling of Python comparison

In case of multiple comparisons, previous implementations evaluated all
arguments before doing the comparison. This is a bad behavior, as
evaluation of boolean expression are done lazily.

This improves the performance of the nqueens benchmarks a lot!