WebServer: Fix memory leak - #203

…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.

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