add response wrapper + simple mechanism to ensure safe close handling fo...

...r writer vs outputstream
*TL; DR*

I think it's ok without `@volatile`.

*Full*

Having a read through the servlet spec for 2.4 and 2.5, I don't think this is necessary. Per section 2.3.4 of the 2.5 spec

> If a thread created by the application uses the container-managed objects, such as 
the request or response object, those objects must be accessed only within the 
object’s life cycle as defined in sections 3.10 and 5.6. Be aware that other than the 
startAsync, and complete methods, the request and response objects are not 
thread safe. If those objects were accessed in the multiple threads, the access should 
be synchronized or be done through a wrapper to add the thread safety, for instance, 
synchronizing the call of the methods to access the request attribute, or using a local 
output stream for the response object within a thread.

The text from the 2.4 spec is largely the same, minus references to async. I interpret this to mean that request and response objects cannot be deterministically used in different threads unless access to them is explicitly controlled (via synchronization, after which the CPU's cache is flushed to main memory) in those threads. Further, except in the case of async, their behavior is nondeterministic once the request thread has completed its lifecycle.

Further, the wrapped instance is created within the intent's `doFilter` method so the container will not hold a reference to it (for example, to recycle the response for a subsequent request). So it seems to me that the only scenario in which a problem would arise (and volatility may make a difference) is when a user is mutating the underlying response outside of the container's request thread, and in an uncontrolled (ie unsynchronized) manner. In such cases, this flag's reference not being synchronized probably won't make a difference in the face of other problems that may arise from such ill-advised usage.