Optimistic Locking behavior for ZSS dataset REST API

[1000TurquoisePogs]

As opposed to pessimistic locking (zlux/#498, zss/#227), we would like to see optimistic locking where we use an ETag derived from something (TBD) which allows the clients to deal with datasets without establishing a lock the whole time the client is viewing the dataset. Locks are only needed during the REST request (read or write) rather than all the time in between (as we do with pessimistic lock).

Because the lock is not held for the entire time, it means that a second user could modify the dataset on system while the first user is still reading or making local edits.

Therefore, the ETag info is needed so that when the first user goes to save their changes to the system, the system can check to see if the first user's edits are based upon the latest version of the dataset, or an older version. If its an older version, the first user may not want to write the change because it might not be what is desired anymore, and therefore additional headers, arguments, or just restarting from a read would be desired in order to make sure the user knows what they're doing and what the resulting dataset contents will be.

This solution probably does not need the heartbeat logic we wrote in pessimistic locking because a lock is not held throughout the operations. Locks start and end within a single REST request.

[1000TurquoisePogs]

ZSS side complete in zowe/zss#355 and editor side nearly complete, probably end of sprint.