Avoid raising a SystemError when clearing slots if setstate() failed.

PR #52 introduced a code path to `ghostify` that calls PyErr_Clear()
with the intent to avoid propagating AttributeErrors for slots.

However, if there is an error (like a POSKeyError) raised by
jar.setstate(), then `unghostify` will call ghostify with an error
pending. If the object had slots that weren't set and the
AttributeError was cleared, so was the pending error from setstate. So
when `ghostify` returned NULL that got propagated up to the
interpreter which finds no exception and so raises `SystemError: error
return without exception set`.

This commit makes `unghostify` save and restore the exception state
around the call to PyErr_Clear.

Fix ``__setstate__`` interning when ``state`` parameter is not a built-in dict

Use macpython for all Mac builds.

Ref #58

Python 3.6 Mac

Support Python 3.6

new_ghost shouldn't clear newargs (PyPy consistent with C)

Expose PersistentList/Mapping docs. Fixes #52.

PickleCache.

Fixes #49.

Unfortunately, this doesn't fix the whole problem, because
_p_deactivate() still clears them, and so we lose what we set in __new__.

@jimfulton and I have talked about it, and I'm (mostly :) convinced that
this shouldn't be an actual problem for any of the reasons described in
the previous comment.

If I use PyPy 5.4.1 to run the ZODB master test suite against
this (well, with #44 rolled back) I don't get any unexpected
failures. (I haven't run the ZEO test suite yet.) Which honestly amazes
me because I'm sure I used to get test failures---I guess the PyPy GC
has changed...which means we may see some failures on Travis. I'll try
to set up an older PyPy to verify.

Fix Python timestamp hash on 64-bit windows

This reverts commit 358cd618.

The _wraparound function is still broken on PyPy3 (both the old version
on Travis and the latest available) if we don't use ctypes.

Fixes #51

Part of the problem was in the tests. The detection of when the hash
gets truncated was broken on win32.

Part of the problem is somewhere in the _wraparound function, I think,
because even fixing the tests to use the right values we still get
mismatches. Rather than dig into that, I just go back to using ctypes
when it's available.

py/deactivate vs slots: A slot variable could not be initialized at all

fe2219f4 (On deactivate release in-slots objects too) started to release
objects from slotted variables but was not careful enough while doing so: we
have to be careful while deleting as for unset variables it will raise
AttributeError:

    class C(object):
        __slots__ = ['aaa', 'unset']

        def __init__(self, aaa):
            self.aaa = 1

    c = C(111)
    del c.aaa
    del c.unset

    Traceback (most recent call last):
      File "y.py", line 9, in <module>
        del c.unset
    AttributeError: unset

Caught by preparing fix for https://github.com/zopefoundation/persistent/pull/44#issuecomment-256768600

C version already have this protection in the original fe2219f4 patch:

    +            if (PyObject_GenericSetAttr((PyObject *)self, name, NULL) < 0)
    +                /* delattr of non-set slot will raise AttributeError - we
    +                 * simply ignore. */
    +                PyErr_Clear();

On deactivate release in-slots objects only for classes that don't ov…

Commit fe2219f4 taught Persistent to release in-slots objects on
deactivation. That however broke pure-python implementation of many
things because they were using __slots__ as a place which survive
deactivation.

As per discussion in

    https://github.com/zopefoundation/persistent/pull/44

and resolution:

    https://github.com/zopefoundation/persistent/pull/44#issuecomment-261019084

let's try to preserve backward compatibility by not releasing slots for
classes that override __new__

/proposed-by-and-helped @jimfulton