Add a way to force Maestro to run a certain subscription as if its trigger file changed

[dagood]

This would allow easy end-to-end testing of subscriptions.json changes and easy retries when triggered builds fail. The retry target should be a subscription, not a file, to avoid forcing other subscriptions to run unnecessarily.

/cc @MichaelSimons @naamunds

[dagood]

Being able to have Maestro use the subscriptions.json from a PR branch would be extra cool, so we can test a subscription change E2E before merging it.

[MichaelSimons]

Requirements

1. Should not assume handlers are VSTS build definitions. Down the road there may be other handler types. This feature should work with them without changes.
2. The means to trigger the subscription should be easily consumable by end user. (e.g. should not need to install anything)
3. Down the road, it may make sense to integrate the end user experience into MC. The design should support this desire.
4. It is not necessary to simulate a file change rather the core requirement is simply support invoking a particular subscription on demand.
5. The means to trigger subscriptions must be secured.

Proposal

Maestro already makes use of an Azure Queue as a way for the WebApi to invoke a WebJob (with optional delay). The WebApi does this in response to a GitHub commit. The WebJob's responsibility is to simply invoke the subscription handler. Another Azure Queue could be created to support invoking a specific subscription on demand. The idea would be that each subscription would need a unique id/name. To invoke it a message with the subscription name would need to be queued. In response to this, a WebJob would then invoke the subscription handler. Needless to say, the existing Maestro logic should be refactored/shared as appropriate when implementing this new functionality.

To make it easy for end users to trigger a subscription manually, a new VSTS build definition can be created which contains a parameter for the name of the subscription to trigger. The build definition would contain the logic dealing with the Azure Queue. This would be the same logic that MC would need if we ever decided to integrate Maestro into it. The build definition would also contain the secrets for working with the Azure Queue.