Format BigDecimal values in hidden fields and drop-down options according to locale

[jenshp]

When received and processed in a transition, these field's values will be treated as if in user's locale, so this change is required for a DB roundtrip through the browser to work smoothly. This solves the server part of #49
It affects the value of hidden fields and options, as well as the current value in drop-down fields. The developer should, however, be locale aware if using the expandable key and text attributes of tags like entity-option and list-option, adding "${ec.l10n.format(keyName, null)} instead of just "${keyName}" for the code to work using a locale with comma as decimal separator. Making this aspect transparent to the developer would require to modify the behavior of ResourceFacade.expand(...) to make the transformation into the locale-aware format, which could affect other uses of that method.

[jonesde]

Honestly, I'm never going to merge this. It is a partial solution to a much bigger issue that needs a lot more effort for testing different scenarios (which need to be defined) and overall handling of numbers with comma as the decimal separator. Even supporting this for only BigDecimal is inadequate, what about Double and other decimal number objects? What about pretty much every other instance of call to the toPlainString() method? There are lots of them about.