Adds a control to the preferences dialog that allows a different
translation (*.qm) file to be loaded for the main application - and the
Qt libraries themselves - to change language.

Also inserts some initial translation source and compiled files that I have
been using to test GUI language change features for British-English and
French-French they are not complete but do show the effects of changing
language - in the interests of supporting other Mudlet developers with
their own language interests there are also even less well populated
Russian, German and Simplified Chinese but it is fairly painless to add
others - there are some notes in the mudlet.pro project file and the
dlgProfilePreferences constructor.

Also inserts code into some other classes to respond to
QEvent::LanguageChange:
* TConsole
* dlgIRC

In passing found that there is no need for a separate "enable spellchecking"
checkBox in the same tab of the options/preferences dialog as the GUI
language change option is placed as the same effect can be achieved by
the intrinsic checkbox that all groupBoxes have if it is enabled. This
saves a small amount of space on that tab of the dialogue!

=== IMPORTANT ===
If using the Qt Creator IDE ensure that in the:
"Options" dialog -> "C++" item -> "Qt Class Generation" tab the:
"Support for changing language at runtime" option is CHECKED.

This will ensure that the files produced by the forms compiler include the
retranslateUi(QWidget *) method which needs to be called on Language
Change to tell the generated forms (dialogues) to repaint their
textual content in a (new) language.  The source of that method is the
(hidden) "ui_FORM_NAME.h" include file that our classes that work with
the generated form code (made from the "src/ui/FORM_NAME.ui" form
definition (XML) files that the Qt Designer plug-in/stand-alone utility
creates) uses. For the record those header files are also the source
of the "setupUi(QWidget *)" methods that can be seen near the top of
the constructors for some of the Mudlet classes that use forms...
=================

Also as part of a BugFix for Mudlet#1273 there is a partially complete update
to show more non-GPL code licences in the "About" dialog's third tab.

This and other forms/dialogues have been refactored to bring HTML code
into the C++ core from the Form file ui/*.ui files to make it easier to
(re)-translate such texts.

Also added missing licence boiler-plate to 3rdparty/lua_yajl/lua_yajl.c
to properly attribute it to its creator.

Also narrowed the licence used for
3rdpaty/communi/src/3rdparty/mozilla/rdf_utils.c to GPL 2+ from the triplet
which included that option in the original file as the text there says we
may - so that the code has the same licence as we use for the main part of
our code.

Made ircmessageformatter correct for lua(not-translatable) / other use

This means NOT using tr(...) for cases where the boolean isForLua is set
in the various methods in this class and also not using HTML/Rich Text.

It also means using something other than any raw string literals which has
been enforced with the inclusion of the #define QT_NO_CAST_FROM_ASCII and
QT_NO_CAST_TO_ASCII which will cause compilation to fail in any case where
such literals ARE used.  Typically a QString will instead be wrapped with
a QLatin1String(...) wrapper should it be a true constant and destined for
a method/function call that has a QLatin1String form or a
QStringLiteral(...) form should it require positional argument replacements
(as QString::arg(...)) in the same way that the tr(...) form does - but not
as something that is subject to translation.

Also fixes a few argument number errors in QString::arg(...) codes in:
* (QString) IrcMessageFormatter::formatTopicMessage(IrcTopicMessage*, bool)
* (QString) IrcMessageFormatter::formatInviteMessage(IrcInviteMessage*,
                                                                      bool)

Made dlgTriggerEditor support run-time language changing

It also means adding support for language changing to related classes:
* dlgActionMainArea
* dlgAliasMainArea
* dlgKeysMainArea
* dlgScriptsMainArea
* dlgTimersMainArea
* dlgTriggersMainArea
* dlgVarsMainArea

Make T2DMap better suited to translation

For many texts that are subject to translation we use Rich/HTML text and
in the past I have hidden the open and closing HTML paragraph tags in the
none translatable part of the strings.  However should the content extend
to be more than one paragraph the translator would have to remember to
close the first paragraph with a </p> and then open a one with <p>.

By not including the outer pair of tags it is less clear to translators,
IMHO what might be going on so they have been restored to the texts that
translators would see.

This commit also moves various entries - manly tooltips and mainly HTML,
from the form definitions into the C++ source which makes it possible to
de-obfuscate the HTML that later versions of the Qt Designer plugin/utility
insist on making more complex even though a long standing QTBUG means that
Qt Linguist is unable to display HTML markup in a way that makes it
editable by translators!

Also wrap some raw strings in QStringLiteral/QLatin1String wrappers to hide
them from translation system and others into it.

Made dlgComposer more amenable to GUI translation

Added sysGuiLanguageChange & getGuiLanguageCode() for Lua subsystem

This causes a sysGuiLangageChange event to be sent to all loaded profiles
when the user changes the setting in the preferences.  Two additional
arguments are passed being the "XX" or "XX-yy" {XX is language;
yy is Country} codes for the new followed by the old translation codes.

Additionally a script/package can query the current setting with the
getGuiLanguageCode() which returns the same type of code which could, in
theory, allow package creators to tailor their scripts for more than one
language - of course for API simplicity the Mudlet Lua implementation is
not translated.

Made TConsole more amiable to translation

Convert 4 error messages that are bound for the Lua subsystem from tr(...)
to QStringLiteral(...) so they are not subject to translation process.

Correct/fixup some messages in TAlias

One of the emended lines raised a parsing issue with lupdate {the:
R"(in: ")" line, then 263 causes a "Excess closing parenthesis in C++ code
(or abuse of the C++ preprocessor)" warning} I rewrote it and also
arranged for it and a couple of related messages to be translatable when
they may not have been before - and they are sent to the Central Debug
Console and the Error display label in the top of the Editor Dialog so do
constitute GUI elements IMHO.

Make dlgPackageExporter class work for subDirs & translatable

It was found that the form used for this dialog was not configured in a
manner consistent with the Qt IDE:
"Tools" -> "Options" -> "C++" -> "Qt Class Generation"
  -> "Embedding of the UI Class"
setting of "Multiple Inheritance" that has been used for (most ?) other
forms/dialog - so this commit includes switching some code over to that
form.  This revealed that the class member "filePath" was masking/shadowing
a dialog member (a QLineEdit) of the same name.  I renamed the latter to
lineEdit_filePath and then found that the class member was largely
redundant as the textual content of the lineEdit contains the wanted
detail.

I also renamed a couple of other items in the form:
* (QLabel *) textLabel1 ==> textLabel_exportLocation
* (QLabel *) textLabel1_2 ==> textLabel_informationText
to be a bit better named.

It became clear that it would be possible and might be useful to show the
lineEdit contents (in readOnly mode) once it was populated.

There was an issue with the creation of temporary files/directories in
that they were assembled in a sub-directory:
"mudlet home dir"/profiles/"profile name"/tmp/"package-name"
folder that was not cleared after the creation of a module and so would
not be a "temporary" one and would still be around should another instance
of the same package/module be assembled.  This commit changes that to
have the option to properly use an OS-dependent temporary location and
which is removed now after the package is created (unless a debugging line
is un-commented) or which (in the linux case "/tmp") has a well-known
(to the OS) as being likely to be subject to temporary file clean-up.

More fundamentally it became clear that the existing code DID NOT WORK to
produce modules if there were any sub-directories and in the absence of any
error reporting it was not clear why. This commit changes the way that the
user created files and sub-directories are scanned to pick up on
sub-directories and to make the needed but missing entries in the archive
for them.  It also arranges for the "config.lua" file to be stored as the
first "file" in the archive and the Mudlet items in the
"'package-name'.xml" file to be the last (so that all the other contained
files are loaded in before it is used in any way.

The form/dialog has been simplified a little with a more informative text
(which has been brought into the C++ code to make it easier for translators
to work with {some of the fixed HTML has been hidden from them}) and it
now persists for around 10 seconds after the "Export" button has been hit
so that the "results label" which is now populated with a
"success / fail + reason" message is at least briefly readable.  In the
past only a success message was shown and as the form was being hidden as
part of the "close()" method called immediately after it was put up it was
never seen...!

Differences between the form object name and the ".ui" file that contains
their definition was causing confusion in Qt Linguist as it was not clear
of the context for some entries.  However renaming the object meant that
where they were inherited in various Mudlet class header files needed
emending to match...

Names changed:
color_trigger_dlg ==> color_trigger
profile_dialog ==> connection_profiles
irc_dlg ==> irc
keys_main_area ==> keybindings_main_area
NotesEditor ==> notes_editor
roomExits ==> room_exits
MainWindow ==> main_window

Some forms also referred to the old mudlet_alpha.qrc resource file instead
of the correct mudlet.qrc one.

As it has been a while since some forms were edited in any way, a small
change in the format (removal of an unneeded space character between the
last attribute in XML entity and the closing '>') has also modified some
form (.ui) files edited in some other way...

Also fixed a spelling mistake (overide ==> override) in my source code.

I did lose a set of changes that I accidently deleted and recovered
by delving in the ./.git/lost-found/other area for blobs of
changed files - hopefully I managed to rescue all the bits
needed...

Some versions of Qt's lupdate seems to have issues parsing modern C++11(?)
string literals and get confused when there are an odd number of, possibly
escaped/embedded double quotations (or that is what I found) however
reverting to the prior form involving back-slashes '\' seems to work.

The default scripts/commands built-in to Qt Creator do not:
* produce a reduced "plurals only" en_US which is all that we need for
  American English
* mark untranslated strings - Qt Linguist does with a '#'
* compress the binary files to save space

I enclose a couple of shell scripts unix_lupdate.sh and unix_lrelease.sh
that should be executable from within the QtCreator environment
(or included in qmake/cmake project files) that should automate updating
translation source files and producing binary translation output files
that can be used now. They should be executed from the ./src/
sub-directory.

At present the translation binary files are expected to be in the same
directory as the Mudlet executable - but this is not be satisfactory for
all situations and will need further revision.  In the mean time for (unix)
developers it is useful to include symbolic links from the "build" shadow
directory to the ./src/ one so that a development executable sees the
translation binaries as they are updated.

Only the en_US; en_GB and fr_FR files included significant translation
work at present, the first two are largely usable and the French one
includes many prototype translations in order to test various features,
I would like to think that it is a basis for future work but a native
French speaker would probably think it is absolute "merde"...

On the other hand as an British speaker the middle one does help to remove
the stress I get that is centred around not seeing colour!

Revised I18n "[ XXXX ] - aaa bbb ccc." cTelnet::postMessage(...) system

This needed revision to allow for message tags to have different lengths in
different languages.  May still not be good enough to work with texts
containing combining diacriticals or non-BMP plane characters...

Tidied up mudlet class items, move some permanents into class

For dynamic GUI language changes we will need to change the texts and
tool-tips assigned to many parts of the main window but until now the
QActions concerned have not explicitly been members of this class - so
retrieving them later for amendment is awkward.  This commit moves the
following into the class (and renames them accordingly):
actionConnect         ==> mpActionConnect
actionTriggers        ==> mpActionTriggers
actionAlias           ==> mpActionAlias
actionTimers          ==> mpActionTimers
actionButtons         ==> mpActionButtons
actionScripts         ==> mpActionScripts
actionKeys            ==> mpActionKeys
actionVars            ==> mpActionVars
actionIRC             ==> mpActionIRC
actionMapper          ==> mpActionMapper
actionHelp            ==> mpActionHelp
actionOptions         ==> mpActionHelp
actionNotes           ==> mpActionNotes
actionPackageM        ==> mpActionPackageM
actionModuleM         ==> mpActionModuleM
actionReplay          ==> mpActionReplay
actionMultiView       ==> mpActionMultiView
actionStopAllTriggers ==> mpActionStopAllTriggers
actionAbout           ==> mpActionAbout
The following is only used in some circumstances, it is set to a null
pointer when not (and I corrected a spelling mistake!):
actionFullScreeniew   ==> mpActionFullScreenView
The following were already members of the class but it was not obvious from
their previous names:
actionReconnect       ==> mpActionReconnect
actionReplaySpeedDown ==> mpActionReplaySpeedDown
actionReplaySpeedUp   ==> mpActionReplaySpeedUp
actionSpeedDisplay    ==> mpActionSpeedDisplay
actionReplayTime      ==> mpActionReplayTime
Also:
(QToolBar *)replayToolBar      ==> mpToolBarReplay
(QLabel *)replaySpeedDisplay   ==> mpLabelReplaySpeedDisplay
(QLabel *)replayTime           ==> mpLabelReplayTime
(QTimer *)replayTimer          ==> mpTimerReplay

Many of the edited items had tooltips (though a few had status tips
instead) as the items are generated by the Mudlet application rather than
from a Qt Designer form they will not get modified if there is a change
in the translation file(s) during an application runtime; code that sets
those items up/changes them has been placed in a new private method:
(void) mudlet::guiLanguageChange(void) to be called when needed.

There were also many "dead" QActions (mainly with an 'm' prefix that were
declared but never used in a meaningful way, they have been deleted:
mactionConnect, mactionTriggers, mactionTriggers, mactionTriggers,
mactionButtons, mactionButtons, mactionKeys, mactionKeys, mactionHelp,
mactionOptions, mactionMultiView, mactionAbout & mactionCloseProfile.

Make class member pointers in TConsole to bottom toolbar buttons so that
they can be found after the end of the constructor so that their tool-tips
can be revised if the GUI language changes.  As we now have those pointers
we can also arrange for the tool-tips to relate to the toolbar button
current state.  Whilst "wiring this up" I spotted that there was a useless
function call from:
(void) TTextEdit::slot_copySelectionToClipboard()
to:
(void) TTextEdit::copySelectionToClipboard()
and from:
(void) TTextEdit::slot_copySelectionToClipboardHTML()
to:
(void) TTextEdit::copySelectionToClipboardHTML()
where the functions wthout the "slot_" prefix could be renamed to have it
and be called directly.  Also I could changed
(void) TTextEdit::slot_toggleTimeStamps()
to
(bool) TTextEdit::toggleTimeStamps()
so that it isn't a SLOT and then get it to return the state of the variable
that determines whether time-stamps are showing - this is so the slot
function can be in the TConsole class so that it can modify the time-stamp
control button's tooltip to match the state of the control.

Whilst debugging the changes herein I found that
* (QToolButton *) mudlet::mpActionFullScreenView
needed to be initialised in the constructors initialiser list and spotted
a couple of other variables that were NOT being initialised:
* (bool) mudlet::mIsLoadingLayout
* (bool) mudlet::mHasSavedLayout

I found an issue where, when the same "source" text is used in different
places, then QtLinguist only displays ONE source which can cause issues if one
source text is modified but another is not - however by adding additional
developer diambigution strings each instance is separately displayed - where
this has been done there will be such comments with an identical comment
except for an (X of Y) indication - this may help to ensure that changes
are carried through to all places in the source code when needed. One example
of this is the texts to use for the Server Encoding type ComboBox on the
preferences dialog when one set of translations are use on initialisation but
a different set is used when the GUI Language is changed...

Whilst going through the main window menu bar I noticed it badly needed a
clean-up to remove cruft.  I have taken the liberty of:
* reorganising some items
* adding the same icon where possible as is used on the main toolbar
* adding a quit option to the games menu - as I find when I run the application
  in full screen mode I do NOT have a title-bar with a close button on it and
  there is nothing to click on directly to close Mudlet down without doing
  an un-fullscreen first.
* adding the Qt provided "About Qt" action to the "Help" menu where other Qt
  applications often have it.
* change "Settings" to "Preferences" and "Replay" to "Load Replay"
  so that menu items are identical to toolbar items...

Do not populate or mark as translatable the doubleclick_ignore_lineedit
"text" field in the profile_preferences.ui dialog so that it does not get
"retranslated" should a GUI language change be invoked elsewhere in the
same dialog as that will overwrite any existing contents that were set up
in the dlgProfilePreferences constructor which will be the current profile
settings.

Enjoy

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

Repairs a stupid mistake in #ifdef-ing a couple of Windows specific chunks
of code I made before.

I didn't realise it but I am using a (locally compiled) version 1.x of
libzip but some Debian versions and the Trusty Ubuntu Travis Platform only
comes with an 0.1x version by default (that may not encode UTF-8 paths)
correctly - I am not sure of the exact details) although the source for
libzip {https://nih.at/libzip/libzip.html} has declared the functions that
we were using {zip_add(...) and zip_add_dir(...)} OBSOLETE - however that
is all that is available for those cases so I have added #ifdefs that will
use the later functions {zip_file_add(...) and zip_dir_add(...)} if they
are available.  Whilst this hits two places in the previous part of the PR
there is one more instance in the code base that I have also fixed up in
this way.

As it happens both of these issues have arisen as a result of a reworking
of the package/module handling code which, prior to this PR will silently
FAIL to make packages/modules if there are any files placed in the staging
area in a sub-directory.  That staging area was described as a "temporary"
one but in fact persists beyond the production of a package/module. As part
of the reworking it has been made to have the option (NOT ENABLED BY
DEFAULT) to clean up the temporary area afterwards but if a package/module
is being developed then it is likely that the other resources are likely
wanted to be kept for producing later, updated/revised, ones...

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

Fixed a spurious open C type multi-line comment at start of:
3rdpart/communi/3rparty/mozilla/rdf_utils.c where I had chosen the GPL
only licence and rewritten the header in a manner consistant with the
Mozilla terms provided therein.

With the addition of Q_OBJECT macro into KeyUnit and Host classes
(to allow them to use Qt SIGNALs/SLOTs) it also seems to be necessary
to #include <Q_OBJECT> for some build platforms even though it must be
inherited from one of the other #include s...

Not being totally familiar with the methodology in adding overloaded
helpers for data items to QDataStream::operator<< and
QDataStream::operator>> friend type helpers I did not realise I had to
return the (first) argument reference for the two argument methods.

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

With the inclusion of `Host` and `KeyUnit` classes into the list of those
that use the `Q_OBJECT` macro it means that their header files need to be
moved from the `mudlet_HDRS` variable to the `mudlet_MOC_HDRS` one so that
they get run through the `moc`.

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