i18n: fix non-ASCII mangling under default C locale (#203) - #205

…ing under C locale (amule-project#203)

Three binaries that previously did no locale init at all stayed on the
default "C" locale for their whole lifetime, which made wxConvLibc
(and unicode2char() in StringFunctions.cpp) collapse every non-ASCII
codepoint into '?' or escape it. The classic symptom is a filename
like "La.mujer.danesa.1x02.Un.niño.destrozado" surfacing as
"La.mujer.danesa.1x02.Un.ni\361o" in amuled output, amulecmd, the web
UI, etc. Common deployment trigger: Docker / systemd / cron with
LANG/LC_ALL unset.

Three call-sites:
  * src/amuled.cpp -- aMuleInitLocale() at the top of
    CamuleDaemonApp::Initialize(), right after wxAppConsole::Initialize
    returns and before any wxString -> char* conversion fires.
  * src/utils/fileview/FileView.cpp -- aMuleInitLocale() at the top
    of OnInitCmdLine() (CFileView has no OnInit override, so this is
    the earliest hook wxApp calls).
  * src/utils/cas/cas.c -- inline setlocale(LC_ALL, "") + LC_NUMERIC=C
    at the top of main(). cas is plain C, so calling the C++ helper
    would require linkage shimming for no real win; the inline pair
    matches the helper's policy verbatim.

amule, amule-remote-gui, alc, alcc, and wxcas already drive locale
through wxLocale (m_locale.Init() / InitLocale()), so they're left
alone -- the wxLocale codepath calls setlocale internally and was
never broken in the C-locale sense.

amulecmd and amuleweb get migrated to the new helper in a follow-up
commit so this commit's diff is just "add calls, no replace".

Closes amule-org#203.

…RIC=C)

ExternalConnector.cpp has been calling setlocale(LC_ALL, "") for the
connector binaries since amule-project#626. That fixed unicode2char() output for
non-ASCII filenames but left LC_NUMERIC at whatever the user's locale
specified, which silently breaks any libc printf/scanf decimal path
under e.g. de_DE.UTF-8 ("%.2f" of 3.14 -> "3,14"). The aMuleInitLocale
helper added in the previous commits forces LC_NUMERIC back to "C"
after the LC_ALL grab, eliminating that trap.

Behaviour change: LC_NUMERIC is now always "C" for amulecmd and
amuleweb regardless of the user's environment. Any code that was
silently depending on the user-locale decimal separator in those
binaries now sees "C" decimal. None known to do so; flagging here so
a future bisect can find this line if something surfaces.

Refs amule-org#203.