configuration phase.

New directives: proxy_cache_lock on/off, proxy_cache_lock_timeout.  With
proxy_cache_lock set to on, only one request will be allowed to go to
upstream for a particular cache item.  Others will wait for a response
to appear in cache (or cache lock released) up to proxy_cache_lock_timeout.

Waiting requests will recheck if they have cached response ready (or are
allowed to run) every 500ms.

Note: we intentionally don't intercept NGX_DECLINED possibly returned by
ngx_http_file_cache_read().  This needs more work (possibly safe, but needs
further investigation).  Anyway, it's exceptional situation.

Note: probably there should be a way to disable caching of responses
if there is already one request fetching resource to cache (without waiting
at all).  Two possible ways include another cache lock option ("no_cache")
or using proxy_no_cache with some supplied variable.

Note: probably there should be a way to lock updating requests as well.  For
now "proxy_cache_use_stale updating" is available.

It's possible that configured limit_rate will permit more bytes per
single operation than sendfile_max_chunk.  To protect disk from takeover
by a single client it is necessary to apply sendfile_max_chunk as a limit
regardless of configured limit_rate.

See here for report (in Russian):
http://mailman.nginx.org/pipermail/nginx-ru/2010-March/032806.html

Previous attempt to fix this was in r1658 (0.6.18), though that one wasn't
enough (it was a noop).

If first entry in stsc atom was skipped, and seek was to chunk boundary,
than first_chunk in the generated stsc table wasn't set to 1.

The directives did not work if there were no limit_conn/limit_req specified on
the same level.