Expose StoredWorkflowId in invocation API

[simonbray]

What did you do?

• Expose StoredWorkflowId in the invocation API in addition to WorkflowId
• Allow use of the instance param for the index_invocations and invoke methods (for the others it was already supported). This allows the user to select whether they want to invoke / index workflows using the StoredWorkflowId or WorkflowId.

Why did you make this change?

Almost all interactions with the Galaxy API require the StoredWorkflowId, it's quite confusing (and not that useful) that accessing an invocation provides the WorkflowId. E.g. accessing an invocation, getting the workflow id and attempting to use it to re-invoke the workflow will fail (unless the two IDs are coincidentally the same).

How to test the changes?

(select the most appropriate option; if the latter, provide steps for testing below)

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are as follows:
  1. [add testing steps and prerequisites here if you didn't write automated tests covering all your changes]

License

• I agree to license these contributions under Galaxy's current license.
• I agree to allow the Galaxy committers to license these and all my past contributions to the core galaxy codebase under the MIT license. If this condition is an issue, uncheck and just let us know why with an e-mail to galaxy-committers@lists.galaxyproject.org.

For UI Components

• I've included a screenshot of the changes

[github-actions]

This PR was merged without a "kind/" label, please correct.

[jmchilton]

Awesome, this was definitely needed and I apologize to contributing to the confusion and inconsistency around these endpoints.