tr: Membership spike

[isTravis]

This PR refactors the schema to support members.

In doing so, it also experiments with the idea that we don't need workflows as a wrapper around stages. This comes both from the added complexity of ignoring or adding Workflow members, and feedback from a few demo calls. Based on those conversations with prospective users - the notion of distinct "workflows" doesn't seem obviously necessary and at times even problematic. A flat list of Stages seems to suffice (even if the graph if stages and possible transitions has disconnected subgraphs that in effect constitute a distinct 'workflow').

The benefits of this approach that I see at the moment are:

• Avoids the complexity of introducing of Workflow Members/Integrations. Simple system with just Pubs & Stages
• Allows stages to be re-used across "workflows". You may not need to re-design the Register DOI stage every single time you want to try out a new peer review step. Stage graphs don't have to be fully disconnected and redundant.
• Simplifies expected permissions. If you're added as a member to a stage, can you see all the other stages in a given workflow? Unclear with workflows, clearer (no) with distinct stages. If you want people to see all stages, you just add them as a community admin, or add them to all stages (simplified by use of Member Groups, so you don't have to do that more than once).
• Allows the notion of moving a pub between stages in different "workflows" (because there are no workflows - but might still be disconnected sub-graphs). But this feels important because sometimes a single function is done by a team at a higher scope than the workflow (e.g. legal) - we don't want legal to be on 12 different stages, just one stage with lots of stuff in it.

A few other thoughts about this approach:

• A workflow is really the emergent sub-graph derived based on move constraints. Rather than a top-down grouping.
• It'd be an easy decision to change down the road
  • We could introduce a lightweight workflow that's based on prefixing stages with a workflowName/, and we could visually group stages with same prefix.
  • We could introduce a full-blown workflow with members and integrations and just put all existing stages in a default workflow without needing anyone to migrate.
• A stage allows a certain set of people to take a certain set of actions. That's it. Workflows don't offer much of a definition or capability beyond that - just add a layer of abstraction that may introduce unnecessary complexity.
• We could allow people to define kanban board views that are a subset of stages in some order.