Anti-crash mods

With the appearance of simfiles that have many visual stuff or
"gimmicks", they push the engine to its limits. The changes in this
commit are to avoid some crashes that happen with them.

- Actor.cpp: The assert was changed for just a warn because in some
cases the fDelta time is negative, resulting in a crash with just a
negative number as the reason.

The only side effect found so far is that if a song in a course is ended
prematurely in a course (i.e. F3+W) the actor effects are carried on to
the next song and continue playing.

- GameCommand.cpp/.h:

These 2 functions where made to solve some nasty problems that happen in
OpenITG (so far tested only in the Windows build, they also affect
Stepmania "3.95"):

Appearently the garbage collector doesn't work like it should, so after
several hours of continuous play you may get an "access violation"
crash.
This also happens with some simfiles with "gimmicks" (a perfect example:
Eros & Apollo, from DivinElegy's 2nd Annual Gimmick Competition), these
songs will crash the game after 2-3 rounds.
These functions help to solve these problems by reloading all the
elements that may cause problems, and at the same time ensures that
EVERY pointer is correctly deleted and every texture gets deleted if
isn´t needed anymore.

HOW TO USE:
Just place the respective command inside a XML file, for simplicity's
sake use "Screen<something> background" (Please note: the command type
must be "InitCommand")

Example:
<ActorFrame>
<children>
<Layer Type="Quad" InitCommand="%function(self)
GAMESTATE:DelayedGameCommand( 'reloadtextures' ) end" />
</children>
</ActorFrame>

WHERE TO USE:

You can call ReloadTextures nearly everywhere. It's recommended do this
in ScreenEvaluation<something>".
It's been tested that there aren't any problems doing it in that screen.

However ReloadThemeAndTextures is another story...
You only can call it safely in the following screens:
ScreenNameEntryTraditional, ScreenEnding, and some "caution" screens
(like ScreenCompany).
NEVER call this function in any other screen!!! Doing so will most
probably cause a lot of LUA errors, most of them will make OpenITG
crash.

Additional notes:
As you can see, both functions have their SCREENMAN->SystemMessage
commented out. Why?
Because the user shouldn´t have any indications about this. Shouldn´t
even know that we call them or not.
However they'll still send their comments to the log and/or the output
window

Restrictions:
Reloading textures (or even the theme) is a time & CPU expensive
operation. In the original Boxor hardware it can take half a minute or
more... since this was made to solve problems in windows-based arcade
cabinets, this shouldn´t be a problem (since nearly no one use windows
in a Boxor or equivalent PC).
The biggest bottleneck is the IDE/PATA hdd.. with SATA HDDs this is
nearly instantaneous. (Don't even think about SSD´s, the constant
writing will wear off the drive pretty quickly)