OS X architecture auto-detection is back

This is a long overdue attempt to improve the detection of the correct
architecture flags to use when compiling the readline library on OS X.
The problem is that some of the latest compilers (e.g. MacPorts gcc 4.8.2)
only produce x86_64 code and it is therefore no longer safe to produce
i386 code by default (see issue #28).

Previous attempts looked at which -arch flags are accepted by gcc (commit
f5b6fe7) and which assemblers are installed in /usr/libexec (commit 4f74609).
Both are unreliable and were eventually removed (see issue #5).

The latest attempt compiles *and links* a Hello World with each architecture.
This could of course be done in autoconf using AC_LINK_IFELSE, but hey. This
way I'm at least allowed to set CFLAGS directly.

The use of SDK directories to detect the OS is just as bad (see issues #14,
sysroot anyway, so drop the whole business (only support 10.6+ from now on).
The LDFLAGS variable is also unnecessary.

The plan is to build the readline library with all possible architectures.
When the gnureadline extension is built using the python-config flags (which
can specify a subset of architectures), the linker will pick the appropriate
objects from the static readline library.
Only build the static readline libraries

Not only does this save time, it also avoids producing warnings and error
messages that are specific to shared library creation which can potentially
confuse users during debugging.
Remove all custom compile/link flags for extension

It is time for this bit of cargo-culting to go. The extension is already
built with the flags provided by 'python-config --cflags', which picks
the appropriate architectures and flags to match the corresponding
Python setup. There is therefore no need to override or detect this and
the module will be built as universal if needs be.

The 'strict prototypes' C warning does not have to be suppressed anymore
as the underlying cause has been fixed in recent versions of the module.

After this update, compilation no longer depends on fragile distutils
platform checks and directory name checks. This should address
issues #28, #22 and maybe even #20. Tested on 10.6 System Python and
10.9 Homebrew Python.