Fixes to pasuggs's static analysis issues

John:

I finally did take some time to review the reports and while I agree
there are many false positives reported, there is some goodness in
there, too.  My analysis of the reports follows, ordered in least to
most important.

1 - Reports from test.cpp and unittest.cpp
These were not reviewed due to being test code

2 - All items in mutex.cpp are false positives
CodeSonar didn't deal with the ScopedLock class correctly and
incorrectly identified double-lock and unlocks

3 - All reports against LogFile::WriteUnicodeBOM (target.cpp) are valid
but we don't care
Some form of these will be reported based on what platform the analysis
is performed on

4 - Report against LogFile::Open (target.cpp) is valid but we don't care
In this scenario and usage the race condition doesn't matter

5 - Reports against String::assign (lstring.cpp) are valid and related
@167 we assign bSign = value and @169 we re-assign bSign = number
Since at this point number == value, we can essentially remove the
assignment from within the conditional @169 and both issues will be
resolved.
We could @167 assign bSign = number to keep the same association that
the original code had if that were important.
While a minor issue, I think it would be best to remove the side-effect
assignment within the conditional.

6 - Report against Topic::Send (topic.cpp) is valid
The condition being tested will always be non-null since pCurrentNode is
guaranteed non-NULL at this point of execution and since we're not doing
a dynamic_cast to a Topic, value can never be non-NULL thus the
condition will always evaluate to true.
A minor issue, easy enough to remove the if-check.

7 - Report against TimeStamp::Get (formatter.cpp) is valid
While it is likely very rare, localtime() can return NULL and if it does
we will attempt to dereference it later and likely crash.  It would be
best to put in a check of the return from localtime() and do something
sensible to avoid its later usage.

8 - Reports against String::format_va are false positives but lead to a
greater issue
Ignoring what the reports are actually indicating, what they're dealing
with is the return value from vsnprinf(). The concern here is that the
logic coded for dealing with truncated output is only valid when running
against Microsoft CRT.  A POSIX implementation (such as used by gcc) has
different return semantics for vsnprintf() which leads the code as
implemented to be incorrect for all supported platforms.

My references for behavior are:
Microsoft: http://msdn.microsoft.com/en-us/library/1kt27hek.aspx
OpenGroup:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/vsnprintf.html
(which will lead you here)
Microsoft will return (-1) in an overflow AND error (in which errno
would also be set).  However, a POSIX implementation will only return a
negative value (not just -1) on error and set errno ... and in an
overflow situation, it will still return a positive number indicating
the number of bytes that would've been written and it is up to the
caller to detect the overflow (though only number number of bytes
specified will be written).

Given these descriptions, the code is likely to fail in the error
conditions it is intending guard against when running a non-Microsoft
(or compatible) CRT.