[WFLY-3889] Improve JMX efficiency by avoiding cloning the management mo...

...del

This needs some discussion before going in.

The JIRA this addresses complains about the high cost of cloning the model that the JMX integration incurs.

The original idea behind OperationContext was readResourceFromRoot implied the calling OSH was not registered for resource in question or for one of its parents. So,  I wanted to protect that resource from any modifications by the caller. Say some dodgy subsystem modifying the security realm resources or something. To ensure that, the resource is cloned before returning, so any modifications wouldn't affect the real resource.

The readResource op OTOH only returns resources for address at or below the caller's address. So, any strange stuff would just mean the caller was messing with its own resource. Not good, as readResourceForUpdate should be called, but not so terrible either. So, for this case cloning the resource shouldn't be needed, and IIRC it wasn't part of the original code. I suspect it came in for a refactor.

The fix here is to stop cloning for readResource, and then the JMX integration, which is trustworthy, can switch to that.