Fixed issue #1708: delete cookie inconsitency in Safari

Fixed the issue preventing Appium from deleting some cookies on Safari.  The problem was that Appium was not setting the "Path" field which caused Safari to act as though it could not locate cookies created in previous sessions.  Changes include:

*) Updated ios-controller::setCookie to preserve the invoker's expiry value even when cookie.value is empty. I made this change because backdating the expiry field is the correct way to delete a cookie. We shouldn't force invocations with empty values to delete cookies if the invoker has specified an expiry date. This change shouldn't affect any existing code.
*) ios-controller::setCookie now allows invokers to set the path field and defaults the field to "/" if path is undefined.
*) replaced deprecated toGMTString calls with toUTCString in ios-controller::setCookie.  Afaik, the output strings are the same.
*) Refactored ios-controller::deleteCookies. Replaced the recursive logic and nested conditions with a simple for loop. This makes it much easier to understand, debug, and maintain. It also makes it more performant. I made the change because it was difficult for me to debug.
*) The "deleteAllCookies" test in cookies-base.js will now fail if all cookies are not deleted.
well, currently it's asynchronous code written in a synchronous but non-blocking logic (the event loop is still going, and if someone else made a request to the appium server at the same time, its handled would be interleaved without being blocked). what's confusing is that we're wanting async code to run serially (like sync code would). there are two long-term solutions:

1. use sync (actually blocking) code. this would require rewriting all our methods to use sync versions of the underlying node library methods. this is a bad idea not only because node doesn't recommend using the sync versions (they're less stable), but it'd turn appium requests into blocking processes. when we ultimately open up appium to handle multiple simultaneous requests.

2. use a generators-based async library (like one i wrote: [monocle-js](https://github.com/jlipps/monocle-js) ([video](http://vimeo.com/96425438)--I recommend this for understanding async control flow as well), or maybe [co](https://github.com/visionmedia/co)). this brings back the ability to use sync control flow features (like `for` loops) while remaining non-blocking. downside is this won't be available until the next release of node.

so until \#2 becomes a viable option, we're trying to just keep things clean using the `async` library mentioned earlier. there's a lot of old code (like this section) that wasn't written using that library so it's a bit uglier.