U4-4931 - 6.2 - lock contention & potential application lockdown

See details in issue tracker, this is #384 and #388 re-targeted for 6.2(.2).
Remove locks for the HttpRequest one is fine - even when running async it doesn't mean that two different threads are accessing it at the same time, just means that the processing is moved off of a request thread on to a thread pool thread = still a single thread. But lets not worry about async for now anyways since HttpContext.Current doesn't exist in some async either so we'd have issues there...

We don't really use the HttpRequest one much so far but the idea is to start using at the service layer (possibly) for very simple operations that tend to happen multiple times in a single request that may not be runtime cached. In some cases (as an example) like Examine re-indexing, we may call in to the service layer to retrieve an entity but if we've already resolved it in the current request we don't really want to hit the db again for that request, we can cache it in the current request. These are special cases but in the last couple years I've noticed a number of places where this would be hugely beneficial and improve perf (just don't remember specific ones to show your atm)

In the long run, anything that we want to store in HttpContext.Items should use this provider instead of going direct to HttpContext.Items.