Enhance: provide missing functionality for Map Room User Data

Adds lua commands:
* getAllRoomUserData(roomID): given a roomId number returns a lua table of
  all the user data.
* getRoomUserDataKeys(roomID): given a roomId number returns a lua list of
  all the keys of the user data for that room.
* clearRoomUserDataItem(roomID,key): given a roomId number and a user data
  key removes that key/value pair from the user data for that room. Returns
  true if data was removed, false if not and nil if the room does not exist
  for that roomId number.

Enhance existing commands:
* searchRoomUserData(key, value): given a string "key" and "value" returns
  a list of the roomIDs which contain that value for that key, now returns
  a sorted list of room numbers.
  Additionally extended so, in the absence of a second argument:
* searchRoomUserData(key): given a string "key" returns an ascending
  sorted list (lua table with monotonically incrementing integer keys from
  unity) of the unique values stored against that key in all rooms.

Also:
  Correct (and reformat to revised Mudlet "standard") error messages for
  setRoomUserData() {they referred to getRoomUserData() instead which was
  confusing!} and reformat getRoomUserData() error messages as well.

ALL OF THESE FUNCTIONS:
A) Return messages that can be internationalised, and will return them as
   Utf-8 encoded strings to the Lua subsystem.
B) Accept and pass Utf-8 encoded strings to and from the Lua subsystem, so
   non-ASCII text can be used both as identifiers (keys) for room user data
   items and the data (values) stored under those keys.

The searchRoomUserData functions are linear so may not be particularly fast
for large maps - the user is encouraged to develop/use their own index
systems rather than directly utilise the map room user data if they wish to
optimise actions that requires access across all or a sizeable part of a
large map.

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
BugFix: Fix wrong coloured Lua debug message

In (bool)TLuaInterpreter::compile(const QString & code, QString & errorMsg)
an OK response was being coloured red rather than the dark green that other
messages in similar methods were using.

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Enhance: lua searchRoom() search, allow non-ASCII room names

Update getRoomName(), setRoomName() and searcgRoom() to handle non-ASCII
room name data.  The strings passed to and from the lua subsystem now use
Utf-8 which is a super-set of (backwards compatible with) ASCII.

Also, the original lua command when invoked as searchRoom("string") did a
case insensitive room name search and used the supplied string for a
partial search of all room names in the map.  One or two optional Boolean
arguments can be now supplement the supplied search string for the
room-name, the first, if true, makes the search case sensitive and the
second, requires the string to be a complete match rather than a sub-string
of the room name to be found.  Both of these arguments can make it easier
to find a specific room.

In the same manner as another recent commit addressing map room user data
the error messages from these three lua commands have been made capable of
being translated by the Qt internationalisation system, and the resultant
texts can be passed as utf-8 data to the lua system and to user with
non-ASCII characters.

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Merge pull request #211 from SlySven/fix_luaCompileMessageColour

BugFix: Fix wrong coloured Lua debug message
BugFix: close button on map custom exit dialog not cancelling line drawing

As per http://bugs.launchpad.net/mudlet/+bug/1369041 the built-in dialog
button that some OS/Window systems provide did close the dialog but did not
cancel the custom line drawing process.  This fixes the matter by
connecting the reject() signal that the button produces to code to clean
up.

During debugging this it became clear that: if the custom line dialog was
being displayed but before the user had selected the exit to draw the line
for, it was possible to click on the map and add points to create a line;
this would be for a custom line with an Empty exit name which should not be
permitted.  To prevent this a flag "mDialogLock" was added to the class to
prevent the mouse events that would draw or modify a custom line from
proceeding until the custom line dialog had been used or cancelled.

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
BugFix: Prevent colouring of room exit number tool-tips on room exit dialog

As referred to in https://bugs.launchpad.net/mudlet/+bug/1369040 it has
been found that colouration applied to the room numbers displayed in the
map room exits dialog to indicate their validity was being passed onto
the tool-tips for those elements. The cure is to explicitly apply the
colouration to ONLY the QLineEdits involved.

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Fixup: Remove useless sort operation

Sorting operation is ineffective in the manner it was being used, Lua does
not operate in the way that I had assumed!

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Merge pull request #212 from SlySven/enhanceAndAdd_luaMapUserDataFunctions

Enhance: provide missing functionality for Map Room User Data
Merge pull request #213 from SlySven/enhance_luaRoomNameFunctions

Enhance: lua searchRoom() search, allow non-ASCII room names
Merge pull request #215 from SlySven/fix_ExitDialogButtonOnCustomExitLineDialog

BugFix: close button on map custom exit dialog not cancelling line drawi...
Merge pull request #216 from SlySven/fix_RoomExitsDialogColouredToolTips

BugFix: Prevent colouring of exit number tool-tips on room exit dialog
Update package.cpath for OSX

Update package.cpath os it can find locally-shipped dylibs, and remove the LuaJIT cpath code as we don't use it.

This is actually currently in production for 3.0, I forgot to commit it after I made the fix.
Merge pull request #220 from vadi2/development

Update package.cpath for OSX
Fix: Revise HTML producing code to produce VALID html

HTLM Issues addressed:
* a stray, unopened </span> was being placed at start of body of HTML.
* use of XHTML <br /> instead of correct HTML <br> to force new lines
  in produced HTML text.
* empty lines were not being reproduced when copying from clipboard to
  HTML.
* previously produced HTML was being place all on one line, no line-feeds
  in HTML source - by changing the CSS "white-space" arguments they are now
  put into the produced HTML making it possible to edit it in a normal text
  editor but it should still render correctly.
* the data "type='text/css'" was missing from HTML <style> tags - this is a
  mandatory attribute for that type of tag under HTML 4.01 strict (although
  not for later HTML 5).
* the <title></title> tag-pair was missing from the <head> part of HTML
  documents produced - The <title> element is mandatory for HTML 4.01
  strict.  It is now created with data about the source of the HTML.
* the charset <meta> information was not as far as possible towards the
  start of the HTML <head> as it could have been - it is best practice to
  do this as a parser must restart parsing a document when it encounters
  this type of information that changes the encoding away from the default
  ISO-8859 form.
* the list of mono-spaced fonts in the header CSS data did not include, as
  the first entry, the font that was actually used for the source of the
  HTML data.
* no default font size or line spacing was set which makes different
  browsers behave differently, especially if zooming is used, the
  parameters used now should produce HTML that is as similar as possible
  when showing the same output on most modern GUI-type browsers.
* there was no indication as to Mudlet, being the source of the HTML, as
  the generator of the HTML - this now happens and includes the application
  version data.
* the "copy To HTML on the clipboard" code ( in
  TTextEdit::copySelectionToClipboardHTML() ) did not append the </body> &
  </html> tags to close the end of the document produced.
* the selection of only part of the first line of text onto the clip-board
  did not previously take account of the offset necessary for that line
  to line up with the following lines.
* the use of <span></span> tags requires them to be used inside another
  block element inside the <body></body> part of the HTML document but
  this was not being done. A <div></div> pair now meets that requirement.

Also:

When logging console output to a file the filename was being saved in a
local variable in TConsole::slot_toggleLogging() and not the class member
with the SAME name "mLogFileName" that was defined for the purpose.

The date-time format used for log file names has been changed
from: dd-MM-yyyy#hh-mm-ss
  to: yyyy-MM-dd#hh-mm-ss
so that an alphabetic sort of file-names will agree with a sort on the
file creation/last modified metadata.  This should make it easier to pick
out a wanted log file from a directory listing.

The tool-tip for the "record to log file" TConsole control button is now
synamically modified to reflect the current recording/not recording state.

With these changes the HTML that is produced should pass validation by
the W3C on-line or other HTML validators.

Note: to concatenate multiple log files they may be joined by cutting and
pasting at the <div> and </div> boundaries - possibly with an <hr> to
delimit the join so that they are arranged:
<!doc..><html(1)><head(1)></head(1)><body(1)>
           <div(1)>...</div(1)><hr>
           <div(2)>...</div(2)><hr>
                   ...         <hr>
           <div(n)>...</div(n)></body(n)></html(n)>

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Update: format of modded code & +ed commentted support new text format opts

Adjust code layout for agreed formatting styles (mainly trail opening '{'
on same line as text for conditional code and enforce '{''}' use on single
code line blocks).

Another pending Pull-Request will add one or more additional text
formatting options to console text and this commit adds support for them in
commented out additional code.

Revised tool-tip message for profile preference "log in HTML" option, the
text was out of date as it referred to using the raw (non-HTML) log as
input to test the user's triggers - this functionality is now the separate
"Recording" function.  The tool-tip was not in the HTML form that auto-wrap
the text when displayed, instead it was a single unwrapped line across the
screen.  Add same HTML wrapper to logButton tooltips,

Removed TConsole::mLastBufferLogLine as it was only used by old commented
out logging code (also removed here) probably a remnant of what the
previous paragraph's old tool-tip referred to.

*** THE CODE PRESENT IN THIS BRANCH OF MY PUBLIC REPOSITORY HAS BEEN
RE-BASED TO FOLLOW CHANGES IN THE MAIN CENTRAL REPOSITORY "development"
BRANCH AFTER THE PREVIOUS COMMITS WERE PUBLISHED - THIS MIGHT MESS THINGS
UP - BUT I HOPE NOT! 8-(  ***

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
BugFix: Fix logging of long user input and other lines that get wrapped

Fixes the loss from log files of all but the last line of long lines of
user input and other text that gets automatically wrapped to fit on the
console display.

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>