Dataset workflow plugins (take 2)

This is a simpler proposal for workflow plugins than #108 based on the discussion and work started by @TkTech on plugin extras: https://github.com/ckan/ckan/pull/3072

Plugin extras are hidden JSON fields attached to users, datasets, resources, groups and orgs that are accessible from plugins but not exposed as fields in the API or tracked in revisions/activities by default. By convention plugins namespace the values they store in these fields, e.g. `my_dataset.plugin_extras['approval_workflow']` would be the place an approval-workflow plugin might store its data related to `my_dataset`.

With plugin extras in place a basic approval workflow plugin could store the changed fields for each dataset and resource in plugin extras, and provide views with the IBlueprint or IRoutes interfaces for editing and approving/reverting suggested changes. With the recent activity work in https://github.com/ckan/ckan/pull/3485 and https://github.com/ckan/ckan/pull/3972 it could add activities to record when suggested changes are made and approved/reverted.

This type of workflow plugin doesn't need any other new interface, and would be much simpler to implement than storing and retrieving suggested changes as a new type of activity.

When datasets or resources are deleted the plugin extras are deleted at the same time, no special handling is required. If a dataset is updated directly (e.g. using the `package_update` API) the workflow plugin would be able to discard any proposed change, force the update to fail or attempt to keep the change if the update affects different fields.

Review the plugin-extras work in PR #3072 and the activity work in PRs #3485 and #3972, then trace the IBlueprint and IRoutes interfaces and the package_update API mentioned here. Done would require a concrete, agreed workflow-plugin implementation scope, including how proposed changes and approvals are recorded and handled during direct updates.

Written by the indexing model from the issue text.