[HttpWebRequest] Avoid using the threadpool for synchronous requests

The code path for synchronous requests was the same as the one for
asynchronous ones: the threadpool. It's actually not needed in this
case because the thread is going to wait anyway, so there's no need
to use the threadpool.

This helps in scenarios in which SOA is heavily used:
- The process is hosted under xsp/mono-fastcgi/... which use the threadpool
too.
- If the requests generate other requests to other REST services, the
usage of the threadpool in these cases may interfere with the usage of
the threadpool by xsp/mono-fastcgi/...
- The thread that is serving a request shouldn't request another thread
for a blocking operation, preventing the use of that thread by other
possible incoming requests.

This commit is contributed under the terms of MIT/X11 licence.

(It doesn't cause any breakage in the System test suite.)
[WebConnection] Use just one delegate to init the connection

As suggested by Marek Safar, using WaitCallback without the threadpool
is just fine, so revert back to using one delegate.
Merge pull request #550 from knocte/master

[HttpWebRequest] Avoid using the threadpool for synchronous requests