Silences some warnings that newer versions of the compiler(s) complain about.

1. Some of the string format argument specifiers used `%lu` to display `NSUInteger` values.

`%lu` specifies a type of `unsigned long`, and `NSUInteger` maps to either `unsigned int` or `unsigned long`, depending on whether or not you're targeting a 32-bit or 64-bit ABI, respectively.

On a 32-bit architecture (at least for the architectures / compilers that JSONKit will be used on), `unsigned long` and `unsigned int` just so happen to use the same primitive type- a 4 byte 32-bit value.

On a 64-bit architecture (again, for the architectures / compilers that JSONKit will be used on), `unsigned int` stays the same at 4 bytes, however `unsigned long` grows to 64-bits / 8 bytes.

The long and the short of it is this that using `%lu` allows you to easily support 32-bit and 64-bits with out a lot of effort.

However, technically, the C standard says that `int` and `long` are strictly different ranks, and it's generally considered poor form to take advantage of platform specific details in this case.

The proper fix is to add explicit type casts to `unsigned long`.  This makes the implied behavior explicit, and eliminates the warnings from newer versions of the compiler.

FYI, `gcc` did this for a long time and seems to be something that is either new or enabled by default in `clang` / `Xcode`.

Other good warning flags you should consider enabling by default (from Xcode 4.3):

Implicit Conversion to 32 Bit Type
Suspicious Implicit Conversions
Hidden Local Variables

2. Newer compiler warns about deprecated `id` `isa` usage.

I found jwz's commentary about breaking API's pretty funny: http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-to-the-iphone/
Add a `#ifdef` to silence a `clang` static analyzer false positive warning.

The current (at the time of this writing) version of the `clang` static analyzer is complaing that the `objects` pointer is `NULL`.  This is a false positive warning from the analyzer.