techref: Pub tables and Workflows

[gabestein]

• Fleshes out pub table decisions
• Begins discussing workflows

@djagdish @3mcd @kalilsn @howebenhowe @qweliant

[isTravis]

Perhaps stuffing a bit too much into one PR with this approach, but I think my commits are most helpfully viewed separately (rather than clicking the 'Files Changed' tab on the PR).

• The first commit updates the Pub, PubType, etc models to reflect what we discussed today.
• The second commit takes a pass at initial Workflow and Stages models (along with things like claims, moves, and move constraints).

On the former, I opted for more verbose names as we get our bearing. Field -> MetadataField, Metadata -> MetadataValue.

On the latter, there are definitely some naming conventions that need to be worked out, and considerations I'm sure will come up in our next conversation.

Like last time, you can pull this PR down, run npm run reset and you should get an updated database with generated seed content so you can poke around on the Workflows tab:

[isTravis]

This wasn't my understanding. My understanding was that integrations can cause either internal or external side-effects (perhaps both), and that those were defined as:

• Internal side effects: changes pub metadata
• External side-effects: triggers off-platform events.

The former is internal to our platform (e.g. edits the title, generates a new file, creates a review). The latter is external to our platform (e.g. builds a website, posts to slack, deposits to archival service).

[isTravis]

Reflecting the above comment, my understanding was that integrations cause side-effects (rather than them being two different ways of modifying metadata).