Incorrect runtime hash due to control characters in JSON.stringify results

I'm running into some issues with the runtime parameter hashing of `globalize` due to embedded Unicode control characters being escaped during calls to `JSON.stringify`. This is happening with Left-to-right and Right-to-left control characters (e.g. `\u200e`), and results in the runtime hash not matching the pre-compiled hash value of the formatters.

My environment is a little unique; I am running `globalize` successfully (aside from this issue!) in a Classic ASP page using Microsoft JScript (ECMAScript 3-ish). It does require the use of `es5-shim` and a JSON library, in my case, currently, [json2](https://github.com/douglascrockford/JSON-js).

The issue is that `json2` is [escaping a larger set of Unicode control characters](https://github.com/douglascrockford/JSON-js/blob/master/json2.js#L228) than other JS implementations.

For example, my compiled formatter looks like this:
````
Globalize.a1955837365 = currencyFormatterFn(Globalize("fa-IR").numberFormatter({"maximumFractionDigits":0,"minimumFractionDigits":0,"raw":"‎'DOP' #,##0.00"}));
````

When the arguments for this are stringified, it turns into this:
````
[{"maximumFractionDigits":0,"minimumFractionDigits":0,"raw":"\u200e'DOP' #,##0.00"}]
````
And, when that is hashed, the `\u200e` character is hashed as `[92][117][50][48][48][101]` instead if `[8206]`, resulting in a hash mis-match.

I'm not sure the best way to fix this -- should the hashing algorithm be more robust to handle control characters consistently? Do I need to modify `json2.js` to not escape these characters and behave more like other browsers? I expect the `json2.js` behavior is intentionally the way it is, and the [JSON spec](http://www.json.org) allows for escaping unicode control characters, so this is technically correct, it's just not consistent for use as a hash input.

This seems related to #705, and a fix for that might/should take this into account.