Fix for an obscure bug introduced by revs 46806 and 46808, with a test.

The problem of checking too eagerly for recursive calls is the
following: if a RuntimeError is caused by recursion, and if code needs
to normalize it immediately (as in the 2nd test), then
PyErr_NormalizeException() needs a call to the RuntimeError class to
instantiate it, and this hits the recursion limit again...  causing
PyErr_NormalizeException() to never finish.

Moved this particular recursion check to slot_tp_call(), which is not
involved in instantiating built-in exceptions.

Backport candidate.

Objects/typeobject.c

@@ -4590,7 +4590,16 @@ slot_tp_call(PyObject *self, PyObject *args, PyObject *kwds)
 
 	if (meth == NULL)
 		return NULL;
+
+	/* PyObject_Call() will end up calling slot_tp_call() again if
+	   the object returned for __call__ has __call__ itself defined
+	   upon it.  This can be an infinite recursion if you set
+	   __call__ in a class to an instance of it. */
+	if (Py_EnterRecursiveCall(" in __call__"))
+		return NULL;
 	res = PyObject_Call(meth, args, kwds);
+	Py_LeaveRecursiveCall();
+
 	Py_DECREF(meth);
 	return res;
 }