Ongoing battles against localization

Localization is a tough cookie.  I'm getting reports from French users
about filters that don't apply when OK is pressed.  Based on past
experience with similar bugs from Italian users, this is probably caused
by a failure in some text -> number -> text conversion routine, because
a locale-aware function is misinterpreting a decimal representation, and
returning 0 instead of an actual value.

The hardest part of localization issues like this is that some functions
*do* need to be locale aware - anything that accepts text input from the
user, for example - while everything in the backend must be
locale-unaware, to ensure that data passed between PD functions is
always in standard U.S. format.   Due to the complex interplay between
text and numerical representations in the Processor engine (which passes
all user input as strings, so it can be recorded and played back later),
it's very difficult to know how to solve this bug for all locales.

This commit is my first attempt at forcing all back-end interactions to
use U.S.-style string representations.  I'm relying on a lot of outside
help to test this, and it doesn't help that I'm attempting this in the
midst of Layers work, but given the effort involved in solving the
problem for all locales, I want plenty of time to test...
More localization fixes

This should solve a number of problems for locales where decimal
separators vary from ".".  Additional testing is required to make sure
those locales work in all circumstances, and that I have not broken U.S.
locale behavior.
Remove startup warning

...and resume nightly builds!