Cleanup: Cleaned up R_ProjectSprite() somewhat

Trying to get to the bottom of why sprites which don't fit between
the floor and ceiling visibly "jump" at the end of the first tic.
Merge branch 'master' of ssh://git.code.sf.net/p/deng/code
Removed debugging artefacts left behind in the previous commit
Removed debugging artefacts left behind in the previous commit #2
Fixed: HOM before an InFine script at map start

The finale script is not visible until at least one command has been
executed. This is because the script defines the entire appearance of
the screen (background, etc.) and before something is executed we don't
yet know what to draw.

Now one tick is pre-run for all scripts immediately after they've been
loaded.
Fixed|All Games: Game state change/notification messages should not be hideable

The player has the option of hiding the game message log, however
there are times when a message "must" be shown to the player and
should not be hidden. Such messages should be flagged LMF_NO_HIDE.
libcommon: Write a "Saved screenshot" confirmation message to the player's log

Instead of writing the confirmation message to the console, add this
message to the console player's game message log. This should make it
more obvious that a screenshot was actually saved and hopefully avoid
unnecessarily confusing the user.

Todo for later: The games' player message log is not the ideal place
to display such notifications. The engine could feature a notifcation
subsystem that could be leveraged for this sort of thing.
Fixed: Mishandling of malformed Doom-format sound lumps

Some add-ons include malformed Doom-format (i.e., raw PCM) lump data
with the intention being that the sound should not be played.

A basic well-formed test (there is at least one sample and not more
than the number of bytes in the lump) can be used to catch most of
these and suppress loading of the junk data.

See: http://sourceforge.net/p/deng/bugs/1064/
Optimize: Reduced map load times by a further ~10%

The map entity property value database and definition datasets were
reimplemented making use of a StringPool to store the definitions
and a revised data structure for the property values.

Todo: It would be possible to accelerate the inner workings of the
EntityDatabase class further - more profiling is needed.
Fixed: Warning about Str initialization

Using a proper C++ object for the static string is better because we
don't have to manually initialize the (empty) string contents. Plus
de::Str automatically casts to const Str*.
Fixed: Missing virtual destructor
Minor typo fixes to EntityDatabase apidocs
Cleaned up s_environ.cpp and added a todo comment re a design fault
Fixed|GL: Grab window contents from the front (visible) buffer

The GL default is to read from the back buffer, but screen captures
should be made using the visible, completed frames.
Refactor|BSP Builder: Use a vector for LineDefInfos in the BSP builder

As LineDefs have a contiguous range of indices we can use these to
accelerate the info lookups by placing them in a vector with a 1:1
mapping to LineDefs, allowing O(1) lookups.
Fixed|DEH Reader: [CODEPTR] patches use .bex rules
Fixed: Missing logic for "no bright pixels" case in GL_CalcLuminance()

This case was inadvertently removed in the previous refactoring.
Homepage|Build Repository: Added static packages for Doomsday 1.9.7 and 1.9.8

The build repository does not yet persist build events. Once they
drop out of the build event feed they will cease to exist in the
repository. This means it is currently necessary to manually add
"static" packages for builds which should remain in the repository.

Also fixed a mixup in the package filtering logic.

Todo: Revise the build repository to permanently persist events.
Fixed|Homepage|Build Repository: Homepage build stream widgets do not offset if no previous build

When generating the previous|current|next build stream widgets, the
build event chain was not offset if no previous build exists in the
chain.
Homepage|Build Repository: Added a releaseDate property to iDownloadable

In the case of symbolic packages, there may be no corresponding
BuildEvent in the build repository and (thus no metadata which
can be queried to derive a release date).

All iDownloadables now have a releaseDate property. When a new
AbstractPackage is derived from a file release of a BuildEvent,
we will set the releaseDate property of the package according
to the startDate property of the build event.

This allows the release date of a downloadable to be assigned
manually if need be.