Created ParallelForwardingAppender, use volatile modifier on shutDownRequested

Created a base class AsyncForwardingAppenderBase.

Made AsyncForwardingAppender inherit from AsyncFowardingBase and removed members that are defined in the base class.

Created class ParallelForwardingAppender, inheriting from AsyncForwardingAppenderBase.  This class uses BlockingCollection<T> to implement a lossless async forwarding appender that does not have to sleep in the consumer thread loop.   Created associated unit tests.

Added the volatile modifier to the shutDownRequested member because it is accessed from two different threads and we want to ensure that a cached version of the value is not being read in the subscriber thread loop.

Verified all tests pass.
Oi Vey.   Nice catch.   Clearly a test case is needed for this scenario.  I'm toast tonight from staying up till 4am this morning and then getting up for work at 5:30am.   Have Kempo tomorrow.  I'll try to resume on this Friday or during the weekend.  I really appreciate you taking the time to look at this so closely.  It's funny how threading is still somewhat complicated even when using Tasks.    

What we really want to do is continue when there is an unknown exception while calling FowardLoggingEvent.  Exceptions in the ForEach statement itself are always going to be end of thread conditions.

The code is going to look goofy with a nested try/catch but perhaps that's just the nature of threading code? That or I think it's back to the while loop.   I'm not a fan of restarting a thread.   To do so, I think you would have to raise a purpose built exception that append() then catches to trigger restart of the thread.   It seems kludgey like the nested try/catch but at least with the nested try/catch you don't have threads dying and being created which is expensive.