Fix SF bug #697220, string.strip implementation/doc mismatch

Attempt to make all the various string/unicode *strip methods the same.
 * Doc - add doc for when functions were added
 * UserString
 * string/unicode object methods
 * string module functions
'chars' is used for the last parameter everywhere.

Fix a nasty endcase reported by Armin Rigo in SF bug 618623:
'%2147483647d' % -123 segfaults.  This was because an integer overflow
in a comparison caused the string resize to be skipped.  After fixing
the overflow, this could call _PyString_Resize() with a negative size,
so I (1) test for that and raise MemoryError instead; (2) also added a
test for negative newsize to _PyString_Resize(), raising SystemError
as for all bad arguments.

An identical bug existed in unicodeobject.c, of course.

The string formatting code has a test to switch to Unicode when %s
sees a Unicode argument.  Unfortunately this test was also executed
for %r, because %s and %r share almost all of their code.  This meant
that, if u is a unicode object while repr(u) is an 8-bit string
containing ASCII characters, '%r' % u is a *unicode* string containing
only ASCII characters!

Fixed by executing the test only for %s.

unicodeobject.c 2.169
stringobject.c 2.189

Fix warnings on 64-bit platforms about casts from pointers to ints.
Two of these were real bugs.

These were reported and fixed by Inyeol Lee in SF bug 595350.  The
endswith() bug is already fixed in 2.3; I'll fix the others in
2.3 next.

will trigger splitting on any whitespace.

Add #ifdef PY_USING_UNICODE sections, so that
stringobject.c compiles again with --disable-unicode.

Fixes SF bug http://www.python.org/sf/554912

Repair widespread misuse of _PyString_Resize.  Since it's clear people
don't understand how this function works, also beefed up the docs.  The
most common usage error is of this form (often spread out across gotos):

	if (_PyString_Resize(&s, n) < 0) {
		Py_DECREF(s);
		s = NULL;
		goto outtahere;
	}

The error is that if _PyString_Resize runs out of memory, it automatically
decrefs the input string object s (which also deallocates it, since its
refcount must be 1 upon entry), and sets s to NULL.  So if the "if"
branch ever triggers, it's an error to call Py_DECREF(s):  s is already
NULL!  A correct way to write the above is the simpler (and intended)

	if (_PyString_Resize(&s, n) < 0)
		goto outtahere;

Bugfix candidate.

Original patch(es):
python/dist/src/Objects/fileobject.c:2.161
python/dist/src/Objects/stringobject.c:2.161
python/dist/src/Objects/unicodeobject.c:2.147