Prove design for rehydration of Operation and Operation<T>

Operation types must provide a constructor that allows users to access an existing LRO.

Currently, protocol methods and their convenience APIs that start/complete long-running operations return either Operation or Operation<T>. Neither of these types provides a way to access an existing LRO as required by the guidelines.

This issues tracks the work to provide a proof of concept that we can implement this functionality. An implementation is not required for DPG GA, but will be a DPG v1.1 feature.

[KrzysztofCwalina]

or we add this missing functionality to the base type. i.e. we convinced ourselves that we will be able to support it post v1

[annelo-msft]

Per @KrzysztofCwalina, it is not required to produce a design prior to DPG v1.0 GA. Having considered multiple approaches to design, I believe that any of them can be made to work with design tradeoffs and that all the pieces are in place such that we can add operation rehydration without making breaking changes to the protocol methods on DPG libraries.

Right now, we return Operation or Operation<BinaryData> in the method signatures of methods that invoke long running operations. We don’t expect to change this in the future. If we need to add subtypes of Operation specific to DPG to add functionality in the future, we will require rehydration of the operation or a downcast to the subtype to access that functionality.