Basic number localization

[iwehrman]

This provides extremely basic number localization for NumberInput mainly, and also for the scale values used by export. The display of numbers is handled by the browser by the toLocaleString method of Number objects, and relies on the browser's locale being correctly set, as it has been. The somewhat more complicated issue is parsing arithmetic expressions in NumberInput. This is handled with a hack: we determine if the browser wants to format decimals with a comma, and if so we swap out commas for periods and semicolons (which often separate arguments to mathematical functions in the same locale) with commas. Hence, you sum(1,5; 2,5) is translated to sum(1.5, 2.5) before a handoff to mathjs.eval. After that, it's translated back using toLocaleString again. This doesn't seem great, but it's the approach suggested by the mathjs developer. See josdejong/mathjs#421 and http://mathjs.org/examples/browser/custom_separators.html.html.

Note that this does not attempt to localize color expressions returned by tinycolor. So, for example, you'll see rgba(0, 0, 0, 0.5) instead of, say, rgba(0; 0; 0; 0,5). This is because these are intended to be CSS color expressions, which by definition are not localized. This might be debatable, of course, but I thought I'd start here without digging a hole that didn't seem to need digging.

I'm also vaguely aware that in some locales, percentages are formatted slightly differently, like 50 % instead of 50%. I'll handle that, and any other issues that come up, separately.

Partially addresses #3136.

[baaygun]

This looks good to me, but I'm going to wait for @mcilroyc to review the export code to make sure it's kosher.

[mcilroyc]

Export stuff looks OK to me. One concern that occurred to me is that this will put commas in the filename (via the scale suffix), but that seems OK upon a quick test.

[iwehrman]

I think this is worth merging, and I do not think the ball is currently in my court. What say you @volfied or @mcilroyc?