Export AzureStorageOrchestrationService.GetOrchestrationStateAsync() in IOrchestrationServiceClient

Will it be possible to expose the various `AzureStorageOrchestrationService.GetOrchestrationStateAsync()` overload as part of the `IOrchestrationServiceClient` interface (or some new `IExtendedOrchestrationServiceClient` interface):

```
public async Task> GetOrchestrationStateAsync(CancellationToken cancellationToken = default(CancellationToken));
public async Task> GetOrchestrationStateAsync(DateTime createdTimeFrom, DateTime? createdTimeTo, IEnumerable runtimeStatus, CancellationToken cancellationToken = default(CancellationToken));
public async Task GetOrchestrationStateAsync(DateTime createdTimeFrom, DateTime? createdTimeTo, IEnumerable runtimeStatus, int top, string continuationToken, CancellationToken cancellationToken = default(CancellationToken));
public async Task GetOrchestrationStateAsync(OrchestrationInstanceStatusQueryCondition condition, int top, string continuationToken, CancellationToken cancellationToken = default(CancellationToken));
```

Being able to query for running/pending orchestrations will make it possible to... well... "orchestrate" between then.

For example, looking at the following scenario:

1. User sends a request to provision some resource
2. The system schedules an Orchestration to provision the resource
3. User gets "202 Accepted" from the system
4. User sends a request to delete the resource
5. The system schedules an Orchestration to delete the resource
6. User gets "202 Accepted" from the system

Now the order that the Orchestrations are executed becomes critical.

Of course, I could try to implement a locking/leasing mechanism, and then either fail the request in step 4. Or alternatively, I could wait in the Delete Orchestration until the lock/lease is released. However, that would require adding an additional persistency for the lock/lease. A "simpler" solution will be for the Delete Orchestration to wait for any other Orchestration that is currently running/pending.