Thread-safety contract should be properly documented for NuProcessHandler

[gagarski]

When it comes to having some state inside NuProcessHandler implementation, some questions arise that cannot be answering by reading the Javadoc. Moreover, some examples in this repo contradicts the ideas about thread-safety that you can get from Javadoc.

• Are writes done in onPreStart visible in onStart/onStd*/onExit?
  This is most clear of all< Javadoc says

  this method is invoked before the process is spawned, and is guaranteed to be invoked before any other methods are called.
  Can we treat this "before" as JMM's "happens-before"? Are any writes done is this method visible in other method calls? Discussion in Question: Handlers, volatile and visibility #106 is quite contradictory on this matter.

• Are writes done in onStart visible in onStd*/onExit
  Discussion in Question: Handlers, volatile and visibility #106 and Javadoc suggest that the answer is no. However an example in README.md shows storing nuProcess instance in onStart. Discussion in Question: Handlers, volatile and visibility #106 suggest that this is wrong.
• **Are writes done in onStdOut visible in subsequent onStdOut calls? Are they visible in onExit call?
  In other words, can we have something like a giant StringBuilder to collect stdout of the process?
• (if yes) ** Can we share state between e. g. onStdOut/onStdErr calls?
• **Can we assume that all writes done in the handler visible to the thread that got non-Integer.MIN_VALUE from waitFor
  I'd suggest this to be a naive thing to assume, yet this example shares the state without any synchronization.

[thekalinga]

Reactive streams provides certain guarantees wrt visibility. So, its a reasonable expectation that all libraries that embrace asynchrony give JMM guarantees wrt framework callbacks (or) at the least document guarantees the library does & doesnt provide.

Reference: https://github.com/reactive-streams/reactive-streams-jvm