feat(ui): reworked workflow loading flow

[psychedelicious]

Summary

This PR reworks the workflow loading hooks to standardize their API. We support loading workflows from 4 sources:

• A workflow library ID
• An image
• A File object
• A plain old JavaScript object (e.g. user pastes in a graph)

Previously, the logic to handle these loading sources was scattered and the API to use them was convoluted and inconsistent. This made it difficult to implement a consistent UX for each loading method.

For example, it was rather unpleasant to show a confirmation dialog when there were unsaved changes in the workflow editor, and for some load methods we didn't have a good way to handle success or failure.

The logic is now broken up into 3 pieces:

• One low-level hook that takes an workflow as an unvalidated JS object, validates it, and loads into redux. It displays toasts if there are problems or warnings and logs as needed. No matter the workflow source, we need to validate it before loading it into the UI state.
• Four mid-level hooks to handle the four workflow sources (library, file, image, JS object). Internally, they call the low-level hook to validate and load the workflow. They provide source-specific logic for converting the source into an unvalidated JS object.
• One high-level hook that acts as a single entrypoint for loading a workflow. If there are unsaved changes in the editor, the user is prompted with a dialog to confirm loading. It calls the mid-level hooks.

All places where we load a workflow now use the high-level hook. When loading a workflow, the caller can provide callbacks for success, error and final completion.

Though not included in this PR, this makes it a whole heck of a lot easier to add Save buttons to the unsaved changes dialog.

---

Also changed the unsaved changes dialog button from "Accept" to "Load".

---

Side-note: A really nice DX could be to make the dialog awaitable. So you could do something like:

if (hasUnsavedChanges) {
  // The promise resolves once the user clicks "Load" or cancels/dismisses the modal and you get the response
  const response = await openDialogAndWaitForConfirmationOrCancel()
  if (response === 'cancel') {
    return
  }
}
loadWorkflow()

I couldn't wrap my head around it without making deeper changes so I didn't waste time on it. But something like this would make a lot of otherwise tricky user experiences soooo much easier to implement.

Related Issues / Discussions

n/a

QA Instructions

Try out loading workflows. There are several pathways:

• Generate an image on Canvas. View its metadata, click Graph tab, click copy button. Go to workflow editor in edit mode, click the three dots button at the top right of the builder panel. Hold shift and click load from graph. Paste graph, click convert, load.
• Studio init actions
• Image right-click menu
• Image viewer, press w hotkey
• Image viewer, click the button in the toolbar
• Edit button in workflow library (for user workflow)
• View button in workflow library (for default workflow)
• Click on the workflow card in workflow library (any workflow type)
• Load from file in three dots button at top right of form builder
• Load from file button in workflow library modal

I think that's all, I traced all references to the loading code.

Merge Plan

n/a

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Tests added / updated (if applicable)
• Documentation added / updated (if applicable)
• Updated What's New copy (if doing a release after this PR)

[maryhipp]

Edit: Disregard!

I think this was happening before based on code changes, but the studioDestination: workflows is not working for me - the modal is not open by default as it should be