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.
I looked closer at the code.   ForwardLoggingEvent already has a try/catch, thus the loop will never have an exception due to an exception inside the loop.

The enumerator itself may throw an unknown exception but the conditions under which that is occurring I have to assume are catastrophic.   I have been running similar code with Enterprise Library logging and I have not seen the blocking collection exit on tryget unless it was an appdomain unload which is a ThreadAbort scenario and is unrecoverable.   To respawn the thread runs the risk of getting into an infinite thread spawning loop and that would probably be worse than letting the thread die.

I think the best thing to do for an unknown exception in the enumerator is to simply complete the task after forwarding the exception to the child appenders.   I'll implement that and push it.