Stores locally scoped jQuery/Zepto for use in other Foundation JavaScript modules

The first thing that Foundation.js does is grab either jQuery or Zepto, store it as `libFuncName`, and sends into the Foundation IIFE to be used as `$`. Later in Foundation.js, a version of jQuery or Zepto is stored as `Foundation.zj`, which is then used in all the other Foundation JavaScript files. However, the current codebase does a second jQuery/Zepto check before assigning a value to `Foundation.zj`. It then actually sends along the window-level jQuery or Zepto rather than the version passed in the local scope. While this might work fine from a practical standpoint, it might not be the most efficient or consistent.

However, the current approach breaks down if for some reason a developer needs to use Foundation.js with something other than `jQuery` or `Zepto`. For example, if a user needed to manually override the value of `libFuncName` used in Foundation.js with a different version of jQuery (such as a noConflict version stored as something other than `jQuery`), the value of of `Foundation.zj` would be out of sync between Foundation.js and any other Foundation JavaScript files.

Why would this situation ever arise? I ran into an issue using Foundation's custom forms with an old (unsupported?) version of jQuery (1.6.4, [see jsFiddle](http://jsfiddle.net/SaHDj/3/)). Upgrading jQuery being the potentially large/risky task that it is, I temporarily preferred to run Foundation off a new version of jQuery using noConflict. The way the current codebase is structured didn't allow for this as Foundation files ended up using different version of jQuery.

Perhaps I'm missing something obvious, but it seems like this change would allow for Foundation.js to be more flexible and internally consistent. I'm happy to discuss this further or share more information.

Here are a couple more jsFiddles to further illustrate the issue. Pardon the mass copy/paste.
[Simply passing a different version of jQuery to Foundation's IIFE doesn't work](http://jsfiddle.net/yPcry/6/)

[The simple pull requested change resolves the issue](http://jsfiddle.net/KSJfz/4/)