Json parser optimizations for spine-c.

Various optimizations for Json.c and Json.h.

parse_value uses a switch on starting character and avoids three strncmp
calls in many cases.

parse_number dispatches to strtod (C89) or strtof (C99), which is a
slightly more permissive superset of JSON's RFC4627 number parsing, but
is also quite a bit faster.   More explicit error handling added here
too.

(The parse_value and parse_number changes alone made for a ~1.5x speedup
on our tiny ARM926 platform using uclibc 0.9.30 and gcc 4.3.3.)

Use _stricmp or strcasecmp in Json_strcasecmp.  This one has a tricky
#include issue; it's in <strings.h> in some systems and <string.h> in
others.  Defining _DEFAULT_SOURCE and/or _BSD_SOURCE pulls it into
<string.h> in all of the systems we could find.  This is a noticeable
win, but less than parse_value or parse_number.

Elide NULL checks in almost all functions, insert one during
Json_create.  Everywhere else, the code already explicitly checks and
returns.  skip() keeps a NULL check but pushes it outside the loop, so
we only check it on entry to the method.

Also elide some redundant starting character checks for parse_object
('{') and parse_array ('[') since they're only called from parse_value
and we know the character is correct.  There's an opportunity to do this
also for parse_string, but it's a bit more complicated as it's called
from parse_object as well as parse_value.

For all these elided checks, allow them to reappear if SPINE_JSON_DEBUG
is defined and nonzero.

Spine doesn't use the "prev" field ever, so drop it entirely from the
Json structure unless someone defines SPINE_JSON_HAVE_PREV non-zero.

Pull some of the assignments out of conditionals to placate some of the
higher-warning-level compilers.

A few TODO comments left near some of the other speedup opportunities,
as well as one existing place that might need additional error handling.

(Tested on various x86 and ARM gcc versions, Xcode 5.x series, Visual
Studio 2010 SP1, ARMCC 5.04, and MWCCARM 4.0.  Holler if this should be
decomposed into a patch series, if there are any suggestions or idiom
changes, or a different submission method we should be using.)