Feature Request: De-throttling for pipelines and/or collections.

Making a demo got an app frozen at Pipeline.WaitFor

After a while I figured out the reason.
And I agree that for server0like application when first results should be yielded to client before the last item produced it makes little use.

Still I think that potentially blocking features should be made optional, at least on bailout terms.

So I ask for one of (or both) features:
1. `iOmniPipeline.DeThrottle()` procedure with the same use semantics as per `.Throttle`
2. `iOmniBlockingCollection` expanded with `.WasAccessed` function and `.DeThrottle` procedure so pipeline stages could do

`if not output.WasAccessed() then output.DeThrottle()`

This feature would perhaps be even more useful for self-re-fuelling pipelines when the same stage can be both producer and consumer, thus blocking itself on TryAdd would prevent further TryTake and cause self-deadlock..
- https://plus.google.com/+AriochThe/posts/LCHnSCmZYtx
- http://stackoverflow.com/questions/34958285/

Perhaps `IOmniBlockingCollection.IsThrottlingEnabled()` and `IOmniBlockingCollection.IsThrottlingNow()` might be of use too. So if a pipeline stage requires not-throttled collection and can no more change its mode it can explicitly raise exception

Start by tracing the iOmniPipeline.WaitFor behavior and the iOmniBlockingCollection throttling entry points mentioned in the issue. Clarify whether DeThrottle, WasAccessed, or throttling-state queries are required, then define completion as an implemented, documented API with coverage for pipeline and self-refuelling collection behavior.

Written by the indexing model from the issue text.