another attempt to move mem stat into base class

replace llinfos, lldebugs, etc with new LL_INFOS(), LL_DEBUGS(), etc.

cleaning up build
moved most includes of windows.h to llwin32headers.h to disable min/max macros, etc
streamlined Time class and consolidated functionality in BlockTimer class
llfasttimer is no longer included via llstring.h, so had to add it manually in several places

Crashfix: in ll_safe_string not only guard against 0 pointer, but against illegal length of buffer too.

We didn't have any tokenizer suitable for scanning something like a bash
command line. We do have a couple hacks, e.g. LLExternalEditor::tokenize() and
LLCommandLineParser::parseCommandLineString(). Both try to work around
boost::tokenizer limitations; but existing boost::tokenizer support just
doesn't address this case. Neither of the above is available as a general
scanner anyway, and parseCommandLineString() fails outright when passed "".
New getTokens() also distinguishes between "drop delimiters" (e.g. space,
return, newline) to be discarded from the token stream, versus "keep
delimiters" (e.g. "+-*/") to be returned as tokens in their own right.
There's an overload that honors escapes and a more efficient one that doesn't;
each has a convenience overload that returns the scanned string vector rather
than requiring a separate declaration.
Tweak and comment older getTokens() implementation.
Add unit tests for both old and new getTokens() implementations.
Break out StringVec and std::ostream << StringVec from
indra/llcommon/tests/listener.h to StringVec.h: that's coming in handy for a
number of different TUT test sources.

Backed out changeset: 4f3024e9d629

EXP-1693 FIXED the date localization in Item Profile window, Voice Morphs window and in scroll list widget in general.
- Added a customizable date format string to be used for scroll list cell of "date" type.
- The date localization does not change the value of a scroll list cell changing only its string representation.
- Added using localized week days and month names from strings.xml for all locales not only Ja and Pl as it was before.
- Changed the date format in Item Profile window (French locale) as noted in the issue description.
- For this fix the French locale still needs the localization of the following strings in strings.xml:
	<string name="dateTimeWeekdaysNames">
	<string name="dateTimeWeekdaysShortNames">
	<string name="dateTimeMonthNames">
	<string name="dateTimeMonthShortNames">
	<string name="dateTimeDayFormat">
	<string name="dateTimeAM">
	<string name="dateTimePM">

string replacement, e.g. [[FOO]]

The crash was caused by erroneous getting of month name from vector with week day names in LLStringUtil::formatDatetime().
This code woth introduced in June, so though it didn't work properly, it didn't cause the crash(cause June is 5th month). But when
number of current month exceeded number of days in week(this happened in August cause it is 8th) code started getting 8th element from
vector with 7. This caused the crash. It reproduced only on Japanese locale because only there code that caused it was used(see STORM-177
for details). This changeset seems to fix STORM-177 too.

- Used vector with months names where it should be.

Changes:
- Added support for formatting day of the month without leading zero ("sday").
- Changed date format in place profile (landmark info) and in the top status bar
  according to bug reporter's request.

Technical details:
Actually implementation of strftime() in Linux and Windows supports stripping the
leading zero (with "%-d" and "%#d" respectively).
But that's not supported in MacOSX, so I had to reimplement it.

Reviewed by Sergey Litovchuk at https://codereview.productengine.com/secondlife/r/842/

Changes:
- Added support for formatting day of the month without leading zero ("sday").
- Changed date format in place profile (landmark info) and in the top status bar
  according to bug reporter's request.

Technical details:
Actually implementation of strftime() in Linux and Windows supports stripping the
leading zero (with "%-d" and "%#d" respectively).
But that's not supported in MacOSX, so I had to reimplement it.

Reviewed by Sergey Litovchuk at https://codereview.productengine.com/secondlife/r/842/

--HG--
branch : product-engine

--HG--
branch : product-engine

EXT-8318 FIX IMPROVED Code is refactored - avoid using of a separate call of the MultiByteToWideChar to get length of output string.

Assumprion is: wide char buffer requires not more than input string length plus one for a null terminator.

Reviewed by Richard Nelson at https://codereview.productengine.com/secondlife/r/775/

--HG--
branch : product-engine

EXT-8318 ADDITIONAL FIXED ensure that thousands separator is in utf8 format (on Windows) before converting it to LLWString.

Problem on Windows:
==================

LLPanelMainInventory::updateItemcountText() formats number using viewer locale.
non-break space is detected as unknown symbols while converting utf8str_to_wstring when formatted text is set to LLTextBox.

FIX:
===

Added converting of string to multi-byte string and then to utf8 string while formatting on Windows.
  created opposite to "ll_convert_wide_to_string" function "ll_convert_string_to_wide" and helper function to call both of them.
  It is used now to convert result of formatted string while formatting integer number in locale.

Fix affects Windows only.

Reviewed by Richard Nelson at https://codereview.productengine.com/secondlife/r/775/

--HG--
branch : product-engine

Reviewed by Richard Nelson at https://codereview.productengine.com/secondlife/r/775/

--HG--
branch : product-engine

Calling std::locale("fr_FR.UTF-8") crashes on Linux and Mac. Or
rather, it throws an exception when it doesn't know the locale and we
didn't handle the exception. I now catch the exception and output an
error rather than crash.

Note, this happened because of change 703f3bcf7069, which made us
actually pass a real locale string instead of just "C". So, we were
never actually supporting a locale for LLStringUtil::formatNumber().
There is therefore an open task of making formatNumber() actually
respect the locale. I'll report a separate JIRA to capture that task.

Added forward specialization of LLStringUtil::format before use in LLStringUtil::formatDatetime.

--HG--
branch : product-engine

reviewed by Vadim Savchuk https://codereview.productengine.com/secondlife/r/457/

--HG--
branch : product-engine

Reviewed with Leyla

Problem:
* English locale was set for all languages.
* Specifying a correct locale didn't affect anything, including date/time formatting.

My investigation has shown that LLStringUtil was instantiated twice: in the
main binary and in libllcommon.so.
Because LLStringUtil::setLocale() was called from newview and getLocale()
was called from llcommon, they effectively used *different* instances of
LLStringUtil::sLocale. Hence getLocale() always returned empty string.

This seems to be caused by get/setLocale() methods not being dllexported.

The fix instantiates get/setLocale() and sLocale in llcommon and exposes
them to use from newview (i.e. prevents multiple instantiation).

Besides, I specified correct locale names for all languages and platforms.

Reviewed by Leyla: https://codereview.productengine.com/secondlife/r/104/

--HG--
branch : product-engine

--HG--
branch : product-engine

--HG--
branch : product-engine

Reviewed with Brad.

UI widget that references "slt" in the XML.

(merged from viewer-2.0-qa-4)