BugFix: Fix underlines in HTML copy.

The CSS declaration for underlines (and overlines and strike-throughs) is
introduce by the words "text-decoration" NOT "font-decoration", this commit
fixes that error. https://bugs.launchpad.net/mudlet/+bug/1130450 raised
this issue and is solved by it.

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
BugFix/Enhance: Fix underlines in HTML copy, refactor/fix HTML generation.

############################### REBASED ###################################
Intermediate (bugfix only) stage introduced upon another developer's
request - however the end result should be identical - apart from this
comment - to the previous single commit that has been forcible overwritten!
###########################################################################

The CSS declaration for underlines (and overlines and strike-throughs) is
introduce by the words "text-decoration" NOT "font-decoration", this commit
fixes that error. https://bugs.launchpad.net/mudlet/+bug/1130450 raised
this issue and is solved by it.

Also the HTML that the "copyToHTML" context menu item for TConsoles
produced was not being closed at the end and was not W3C standards
compliant:
* missing a mandatory <title></title> entry, now the source is identified
  and thus will appear in the title bar of most modern GUI web browsers.
  "Mudlet MUD Client" and the version is also included in the HTML
  metadata to identify the "generator" of the HTML.
* the charset setting <meta> tag was not the earliest it could be in the
  document {it forces a parser restart when it is encountered} - it is now
  at the earliest point it can be.
* there were few line feeds so later manual editing would have been very
  hard (everything on one line!) - now the layout is naturally broken into
  lines.
* all content was contained in <span></span> tags but these must be inside
  a block element, now a <div></div> has been used as a wrapper.
* no attempt was made to use the font or size of that was being used by the TConsole
  whose text was being reproduced by the method, since this can currently
  be changed for main profile consoles (and might in future be possible for
  user MiniConsoles) this seemed an oversight - this commit attempts to
  address this.

As far as possible QStringLiteral()s have been used to produce the HTML
because using the '+' operator or the .append() method on QStrings is
less efficient when used multiple times to build up a QString - the costs
of combining the data moves more to the compile time when QStringLiteral()
is used - it also silently marks a string that is NOT a candidate for
translation c.f. QObject::tr() method that does the opposite.  A plain
QString( "ASCII sting" ) WILL be noisily noticed once QT_NO_CAST_FROM_ASCII
is defined!

Because all the <span>s are at the same document level the formatting
setting for one does not seem to overwrite the default for the next so that
CSS for "normal" values of fontWeight, fontStyle and textDecoration do not
need to be explicitly included for each span that has those settings, this
reduces somewhat the amount of CSS data in the file.

################################ TODO #####################################
In the future the CSS could be reduced by a great deal more if two passes
were made through the data to include, so that all the difference styles
for all the spans could be identified on the first pass, then included only
once in the header with each span containing a reference to the style it
needed rather than a verbose instance of it in the second pass when the
HTML is actually produced.
###########################################################################

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