Add support for automatically retrying failed requests

[nbrooke]

Also includes some associated cleanup, including:

• Removing the NotificationCenter events for request completion.
• The names and payload of some of the request related LogEvents have changed, generally to include more data on requests (so that can be used instead of the now-removed NotificationCenter events in almost all cases)
• LogEvent.requestCompleted is no longer sent for requests that fail based on non 2xx HTTP codes, just LogEvent.requestFailure.
• LogEvent.requestCompleted renamed to LogEvent.requestSuccess
• Some LogDestination calls would happen on the networking thread, those are now bridged back to the main thread.
• Default logging now logs URLs on request completion, and logs HTTP status codes for HTTP failures
• Change RequestIdentifier to be opaque (it now contains a different unique identifier, since the NSURLSessionTask identifier no longer uniquely identifies a request when retries can happen).
• Centralizing error handling a lot more in the actual network request (rather than logging and calling the completion callback in multiple places, all error handling now funnels through a single catch handler)

[nbrooke]

Made the following changes since the last review:

• Changed the defaults to be more in line with the Slack discussion
• Added Brendan's comment typo fixes
• Made DelayedOperations (I think) thread safe and removed the implicit dependancy on being called on a thread with a valid RunLoop.
• Went ahead and just made it so that we do implicitly bridge all log messages to the main thread. We should probably at some point have a way to turn that off. Even though it's a safer default, for plain old logging (which should itself be thread safe), it is an efficiency loss, and might in a few rare cases cause some logs to appear in the wrong order (i.e. Netable messages out of order relative to system logs also originating on the network thread) or be missing (if, for example, a crash happens between the event happening and the next time the main thread runs).

[nbrooke]

I haven't bumped the version / triggered a release yet, since I'm not totally convinced it's not still going to need some other changes (either to support the stuff I'm doing in Spies, or to maybe address the affect on the project that is using the notification support). I'm just integrating directly from master on Spies, @JeremyChiang you should maybe try pulling the latest in at some point and see if you can get it working reasonably using the LogDestination instead of notification, if there are any changes that need to be made there.