object id hashes resulting in duplicate utility code in specialization

The CppClassType.specialize() method uses a hash table to avoid
re-generating specializations and thus, for example, re-generating utility code:

    # values is a dict where values are instances of classes in
    # PyrexTypes.py
    key = tuple(values.items())
    if key in self.specializations:
        return self.specializations[key]
    # instantiate new CppClassType, eventually resulting in utility code

However, because MemoryViewSliceType used the default (object-id) hash,
distinct MemoryViewSliceType instances would ultimately give rise to
distinct keys. As a result, code like

     def test_memviews_same(a,b):
         cdef vector[double[:]] aa = a
         cdef vector[double[:]] bb = b

would successfully pass through the Cython compiler but then result in a
C++ compiler error due to redefinition of utility code:

    error: redefinition of 'std::vector<__Pyx_memviewslice> __pyx_convert_vector_from_py___Pyx_memviewslice(PyObject*)'

To allow the hash table in CppClassType.specialize() to identify 'equal'
specializations of CppClassType, we can add __hash__() and __eq__()
methods based on the existing
MemoryViewSliceType.same_as_resolved_type() method. Other classes in
PyrexTypes.py also have __hash__() methods defined and the choices made
here appear roughly consistent.

This addition allows the above example to compile successfully.

Calling inherited BaseType.specialization_name() on a
MemoryViewSliceType generates a name like "Pyx_memviewslice", which
meant, for example, that generated utility code could have a name like

    __pyx_convert_from_py__Pyx_memviewslice

which would collide with utility code generated for other memoryviews
that might have other base types. That would mean something like

    def test_memviews_diff(a,b):
        cdef vector[double[:]] aa = a
        cdef vector[int[:]] bb = b

would first have a compile error (function redefinition due to how
utility code is currently generated) and second, if only one such
utility function were emitted instead of one for each memoryview base
type, have problems with any type-specific generated code, e.g.

    // generated inside __Pyx_PyObject_to_MemoryviewSlice,
    // which is called from __pyx_convert_vector_from_py___Pyx_memviewslice
    // note __Pyx_TypeInfo_double
    retcode = __Pyx_ValidateAndInit_memviewslice(axes_specs, 0,
                                                 PyBUF_RECORDS, 1,
                                                 &__Pyx_TypeInfo_double, stack,
                                                 &result, obj);

By adding the dtype tag to the name string returned by
specialization_name(), distinct utility code functions are generated (at
least in the case above) and thus there is no name collision.

always create a new IntNode for the step value in iter-range optimisation as we overwrite its value later

Optimized reversed range with constant negative steps.

extend reversed iteration tests, including disabled tests for negative step values that fail when enabled

--HG--
extra : transplant_source : %F9%BB%B7%FD%A5jc%89%02%BD%BANie%A3%FDc%8F%9Ct

Use PySequence_List, PySequence_Tuple

Cython array import naming conflict

do not depend on reversed(range()) bounds having a numeric type and just use whatever spanning type we find

Optimized reversed-range call when constants are inside of the range.

postpone import of distutils Extension type in test runner in case setuptools gets imported in between

postpone import of distutils Extension type in test runner in case setuptools gets imported in between

--HG--
extra : transplant_source : %9B%C2%08Q%DDt%9A%99%A4%CAK%5D%8F%3A%A9%E4F%19%96%CD

fix test runner and pyximport in Py 2.7.9 and 3.4+: setuptools replaces "distutils.dist.Distribution" *after* we import it, which then breaks the input validation in "distutils.cmd"

fix test runner and pyximport in Py 2.7.9 and 3.4+: setuptools replaces "distutils.dist.Distribution" *after* we import it, which then breaks the input validation in "distutils.cmd"

--HG--
extra : transplant_source : %3A%84%AC%02E%17%D8%EE%E64Mpv%25%A3%8E%8B%E5%CA%19

Minor cleanup (2.5 compat, mostly)

optimize general sorted(x) calls

fix shrinking and overflow in cpython.array