In the pursuit of using less CPU: now trying to avoid blocking queues altogether. Instead, this uses a timer. No sure if it's better or worse, but worth the try.
Revert "MSDN documentation is unclear about whether exiting a lock() block will trigger a Monitor.Wait() to exit, so avoid some locks that don't actually affect the state of the internal queues in the BlockingQueue class."

This reverts commit 42e2a0d66eaa7e322bce817e9e2cc9a288de167b

Reverting because unfortunately this introduces race conditions because Contains(), Count() and GetQueueArray() may now end up returning the wrong result if another thread performs a simultaneous update on m_queue.
Code such as PollServiceRequestManager.Stop() relies on the count being correct otherwise a request may be lost.
Also, though some of the internal queue methods do not affect state, they are not thread-safe and could return the wrong result generating the same problem
lock() generates Monitor.Enter() and Monitor.Exit() under the covers.  Monitor.Exit() does not cause Monitor.Wait() to exist, only Pulse() and PulseAll() will do this
Reverted with agreement.
Revert "Revert "MSDN documentation is unclear about whether exiting a lock() block will trigger a Monitor.Wait() to exit, so avoid some locks that don't actually affect the state of the internal queues in the BlockingQueue class.""

This reverts commit 21a09ad3ad42b24bce4fc04c6bcd6f7d9a80af08.

After more analysis and discussion, it is apparant that the Count(), Contains() and GetQueueArray() cannot be made thread-safe anyway without external locking
And this change appears to have a positive impact on performance.
I still believe that Monitor.Exit() will not release any thread for Monitor.Wait(), as per http://msdn.microsoft.com/en-gb/library/vstudio/system.threading.monitor.exit%28v=vs.100%29.aspx
so this should in theory make no difference, though mono implementation issues could possibly be coming into play.
minor: Add warning method doc about possibly inconsistent results returned from BlockingQueue.Contains(), Count() and GetQueueArray()
Eliminated the UserManagement/UserManagementModule throttle thread. Made the other one generic, taking any continuation.
Changed the name to ServiceThrottle/ServiceThrottleModule in order to reflect its more generic nature.
Added IServiceThrottleModule.cs
Merge branch 'master' of ssh://opensimulator.org/var/git/opensim
Deleted a couple of verbose messages
Attachments module only registers when enabled. This enables alternative attachments module implementations. All calls to Scene.AttachmentsModule are checking for null. Ideally, if we support disabling attachments then we need a null attachments module to register with the scene.
Added config var to fiddle with the Interval for the service throttle thread
Merge branch 'master' of ssh://opensimulator.org/var/git/opensim
UserManagementModule: in the continuation, call the method that also looks up the cache, because the resource may be here in the meantime
Improvements to the ServiceThrottleModule: added a category and an itemid to the interface, so that duplicate requests aren't enqueued more than once.
Removed the MapItems thread. Redirected the map items requests to the services throttle thread. Didn't change anything in how that processor is implemented, for better or for worse.
BulletSim: fix small bug where everything looked like it was colliding
before the first simulator step.
Cleared up much confusion in PollServiceRequestManager. Here's the history:
When Melanie added the web fetch inventory throttle to core, she made the long poll requests (EQs) effectively be handled on an active loop. All those requests, if they existed, were being constantly dequeued, checked for events (which most often they didn't have), and requeued again. This was an active loop thread on a 100ms cycle!
This fixes the issue. Now the inventory requests, if they aren't ready to be served, are placed directly back in the queue, but the long poll requests aren't placed there until there are events ready to be sent or timeout has been reached.
This puts the LongPollServiceWatcherThread back to 1sec cycle, as it was before.
Merge branch 'master' of ssh://opensimulator.org/var/git/opensim
Didn't mean to commit this change in BlockingQueue.cs
Putting the requests back in the queue while testing for count >0 is not the smartest move...