Design and implement REST API and CAS file versioning scheme

We have not had to worry about REST API and CAS file schema changes because we don't have any downstream clients actually using the API. But we need to have a clear process going forward.

Every time a softfork is introduced, backward compatibility WILL BE BROKEN for one or more of the following four components:

1. Observer.
1. Resolver.
1. Batch writer.
1. REST API.

This means a mandatory software upgrade is required by the affected component.

This issue deals specifically with backward compatibility breaks to the existing REST API. In such event, it is foreseen that backward compatibility for one or more other components will also almost always break.

The proposed design is to introduce a `version` property in the suffix/signed data of every operation request, such that Observer, Resolver, and Batch Writer can detect request version and handle them accordingly. The absence of the `version` property denotes v1.0.0

This `version` property is defined by the implementation and may not reflect the version number of the specification the implementation is based on.

It is possible that the different version of parsers of different versions of the operation requests are further decoupled from the implementation of the general "versioning" feature.