BugFix: Overhauls and fixes multiple issues with Replays

The replay code is not re-entrant and has some bugs, this commit:

* prevents a second replay from being initiated if one is already in
progress as a second one would overwrite the pointer to the existing
toolbar whether it was for the profile that the first one was for or a
different one.  This would cause the first toolbar to be "orphaned" in that
it would still exist but would not be accessible and would only "go away"
upon program termination.  A warning message is displayed in the console
of the profile for which the second replay is requested.

* makes sure that the size and style of the replay toolBar is set when it
is created, AND modified when the toolbar size is changed in the
preferences. The absence of this code meant previously that the "faster"
and "slower" icons on the replay toolbar were small blank squares and did
not change if the setting that controls the size (and style) was adjusted.

* adds cleanup code to undo the actions that start a replay, so that the
series of resources made with "new" each time it runs are now deleted, and
the pointers to them zeroed correctly at the end of the replay.

* moves several components or their pointers in the replay toolbar
permanent members of the mudlet Class which are needed to be retained for
the above.

* reverts a previous commit by Ahmed Charles that removed a method that
if given the name of one profile in use returns the next from the hostpool
if there is one.  This is no longer redundant because this code needs to
check all hosts in the pool are not running a replay before permitting a
new one to be started.

* adds console warning messages and does not try to start a replay if the
replay file can not be opened or read.  A replay can also be initiated
via the lua loadRawFile( filename ) command made available to users,
file-name is relative to the current profile's "log" sub-directory and the
code can (now) load another profile's log-file or one in an arbitrary
location. In this case giving a reason for a failure can help the user to
debug their own code if it uses this Lua command.

WE OUGHT TO APPLY SOME "MAGIC" TO THE ".dat" FILES SO THAT ONLY
"PROPER" LOG FILES ARE PERMITTED TO BE USED!

* allows the error messages to be translated if Mudlet gets
"internationalised".  Also the previous starting and stopping messages are
appropriately tagged so that they are colour coded when displayed in the
profile's console.

* enables the lua loadRawFile() to accept a (path)-file-name containing
UTF-8 encoded characters; this is vital for users on later Windows systems
in some parts of the world which may have such non-ASCII characters in
their "home" directory.

* revised the display of the elapsed time during a replay, previously it
was only updated when a new "chunk" from the replay file was used, for a
log recorded during periods of inactivity (I have one where nothing happens
for over a minute) the time display which displays down to the nearest
second is confusing in it's inactivity.  Now the display is updated every
second but drifts slightly, however the drift is reset when the next chunk
is processed.  Also, support is now given for speeds of less than unity so
that the replay can be viewed in "slow-mo" which can help with debugging
user Lua code.

* enables and disables the replay button on the main toolbar so that a
replay is not now possible to be requested until a profile is loaded or
if one is in progress, the other check referred to above that produces a
warning is more relevant to the request from a lua script; the warning
messages would only be produced after the replay request via this button
had already run through the dialog to select the file so by disabling the
button the user does not get the chance to try and select a file before
finding out a second replay is disabled.

Current limitations in replay code:
-----------------------------------
* The replay toolbar is not obviously linked to a particular profile so if
more than one profile is loaded it may not be obvious to which one it
applies. It may be worth seeing if the profile tab text can be modified for
the one on which the replay is running.
* One primary reason that the replay code cannot be re-entrant is that the
button to start it is on the main toolbar, it would be better if the
control could be move to the profile's console, perhaps alongside the
control that RECORDS the replay...
* There is not currently a way to stop, fast-forward/rewind or pause/resume
a replay.
* Changing the speed of replay only takes effect when the next chunk is
processed so if the user has set a very slow speed for replay and then
encounters a long period of inactivity the effects of the previous point
mean it can take a vvveeerrrrryyy long time for anything to happen.

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Will "Mudlet replay file" do?  It suggests the choosing and activating something that the user has already saved in the file system, not using "file" might hide the subsequent required user actions too much.  I used "RAW" because the user has to have chosen to save the log in that format i.e. with the ".dat" extension (rather that the plain text ".txt" that are also kept in the same directory location) to make use of it.