Improve InMemoryDataTreeModification state management

We are currently tracking only a single boolean state. A typical modification goes through multiple state transitions. For example ready() changes first from OPEN to SEALING and once the seal operation is done it goes to SEALED. DataTreeTip.validate() then expects not only a non-OPEN (for example SEALING) modification, but rather a SEALED one.

The distinction guides state transitions with the explicit acknowledgement that operations may fail, which may require a corrective action, or, as in the case of ready() epilogue throwing a RuntimeException, result in an irrecoverable dead-end. Such dead-ends should be refused to be operated on.