Move the 32 bit launchers as discussed at OpenSimulator Office Hour 9//2/14 http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2014-09-02.
Remove the 32 bit launchers as discussed at OpenSimulator Office Hour 9//2/14 http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2014-09-02. Find the binaries, sources and README in ./share/32BitLaunch if needed.
Don't show the ScrLPS data twice in the WebStats based statistics page.
Cleanup some unused code and configuration entries
If BulletSim is running on its own threads, start this thread via the thread watchdog.

This allows us to see the presence of the permanent thread via the "show threads" console comand.
Also adds the region name to the thread name.
minor: fix indenting from previous commit b08ab1e
Make bulletsim thread alarm if no update for 5 seconds.

The cost is minimal (also done for scene loop) at the benefit of telling us if this thread simply stops for some reason.
Don't need to check separate physics status in bulletsim update since that method is only run for an indepndent thread anyway.

Also remove bulletsim monitored thread from watchdog on shutdown.
Start long-lived thread in IRCConnector via watchdog rather than indepedently, so that it can be seen in "show threads" and stats
For processing outbound http requests in the XMLRPCModule, start the thread through Watchdog for monitoring and stat purposes.
Make LLUDP output queue refill thread active by default, since load tests have shown that this has better scalability.

For testing, previous behaviour can be restored with the console command "debug lludp oqre stop" at runtime.
For monitoring purposes, start non-timeout tasks (which do not currently use a threadpool) via Watchdog.RunInThread() rather than Util.RunThreadNoTimeout()

The functionality is the same but this allow us to monitor such tasks via "show threads" and abort them for test purposes, etc.
Also extends thread names to provide more info (e.g. SendInitialDataToClient says what client the task is for).
Merge branch 'master' into ghosts
Add experimental job engine to see if queueing some existing async work during root agent entry to a region improves perf rather than always attempting to execute everything concurrently

Job engine is controlled via "debug jobengine start|stop|status".
Can only currently be enabled and disabled dynamically at runtime.
Currently only applies to code sending initial region data (objects, other avatar data) to a client.