BugFix: replace global gSysMessage with per Host message stack

The prior system of pushing Error/OK type messages into a global
gSysMessage QStringList where the messages came from cTelnet and
TLuaInterpreter classes as they and the profile were initialised was flawed
because the profile from which they came was not recorded and messages
from one profile leaked into the start up messages of a second, later
profile connection.

This commit uses a QStringList in the cTelnet class which receives messages
via the postMessage(QString) method which has been made public where it was
previously private.  As the destination is the TConsole class which has not
being instantiated at the point that the first messages are created the
postMessage() method stores the messages it receives until one is received
where the TConsole class DOES exist at which time it displays in order all
the stored messages.

The message format that this method processes, with a first line of the
form ".*[.*tag.*].*- +message" tags which correspond to "ERROR","OK",
"INFO","WARN","ALERT" in a case insensitive form are specially coloured.
The tag are converted to all upper case.  If the message has additional
lines they are indented to the same position as the first non-space
character after the hyphen delimiter in the first line, this and at least
one following space must be present (as well as the '[' and ']'
characters).

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>

NB: This won't auto-mege with pull request #34 as they both touch the TLuaInterpreter.cpp file where it loads up the various external modules.  To manually merge: replace the lines from that pull request that appending messages with "gSysMessage << message" with "mpHost->mTelnet.postMessage( message )" and tidy up the messages that are used - they should have a "- " after the "[ tag ]" as the new code indents all but the first line of the message to the first non-space after the "- " on the first line, I'd aimed to give all the messages the same spacing which means some spacing tweaks depending on the "tag" in the message.  Also, additional line-feeds are needed in the Lua error messages to display them better and to space them from the error strings from the Lua interpreter which currently are abutted with not even a space in some cases.