Workflow Task Graph: WorkSpec and related constraints

[azriel91]

Provide traits / types that can be collected into a workflow task graph.

Whether or not to track operation support through an enum.

If an operation is not supported, should we track it via an enum, and require implementors to choose a variant? Maybe not -- it adds complexity to the API that may not be necessary in the common case.

If we had one, it may look like the following snippet:

#[derive(Debug)]
pub enum OpOutputMaybe {
    /// This operation is not supported.
    NotSupported {
        /// Message to display when this operation is run.
        ///
        /// This may be a link to an issue to explain why this is not supported.
        suggestion: Option<String>,
    },
    /// Nothing needs to be done for this to work.
    Unnecessary,
    /// This logic has not been written yet.
    ImplPending {
        /// Message to display when this operation is run.
        ///
        /// This may be a link to an issue to implement this operation.
        suggestion: Option<String>,
    },
}

[azriel91]

Learnings / Thoughts:

• DataInit trait should not be a constraint on the data types, otherwise consumers cannot use third party data types without wrapping them in newtypes then implementing DataInit on the newtypes.
• Data derive should reference peace::data::.. because it's inconvenient to import about 5 other types to get them in scope. For peace_* crates, adding a #[peace_internal] attribute or similar will change the module reference to peace_data::...
• Perhaps add another layer around R<'_, T> + a trait, so that ROption<'_, T> will pass Option<R<'_, T>> to the operation, but RExpect<'_, T> will pass R<'_, T>, but err if T was not in Resources. Or perhaps always return R<'_, T> like we do now, and we require initialization earlier -- Err if any types in borrows/borrow_muts are not initialized.