Add plugin for the custom post type for Projects

[benlk]

Changes

This pull request adds a plugin with the following registrations

• Adds custom post type projects
• Adds "Project Status", "Project Organization Type" and "Project Category" custom taxonomies
• Registers "Contact name", "Contact email", "Organization" and "Video" post meta fields, but doesn't yet finish implementing the metaboxes for them

Why

For #119.

Built as a plugin to enhance future portability of this database, and to keep this concern separate from the child theme if they ever decide to swap away from their current theme.

Testing/Questions

Features that this PR affects:

• adds a new plugin

Questions that need to be answered before merging:

• Is this PR targeting the correct branch in this repository?
• These taxonomies are designated "hierarchical" in order to get a list of terms in the Gutenberg editor, rather than a new-tag tag box.
• Do we want to try to finish the custom meta box for this, or is the standard "Custom Fields" editor enough for admin users? The Custom Fields editor doesn't load all registered custom fields, and so does not provide an easy way for editors to know or set these fields if they are not already set on the post:
  

Steps to test this PR:

1. Enable the "Current.org Local That Works Projects" plugin.

[benlk]

As I'm working through the import process testing, I realized that this is missing one post meta field, now added to #119 (comment): The project link.

[benlk]

Here's an updated screenshot from a test import, showing what the Custom Fields editor looks like when populated from an import or from the submission form:

[joshdarby]

@benlk Since this is a pretty large project, maybe we should merge this (and every other PR for the project) into staging instead of master so that we're able to still merge and deploy master if something comes up.

[joshdarby]

Do we want to try to finish the custom meta box for this, or is the standard "Custom Fields" editor enough for admin users? The Custom Fields editor doesn't load all registered custom fields, and so does not provide an easy way for editors to know or set these fields if they are not already set on the post:

I would prefer if we finish creating the custom metaboxes. Leaving the custom fields editor open for anyone to use will probably cause us lots of headaches in the future.

For example, I can see someone going to add in a value for an accepted field that's not yet included in the current project, for example project-contact-email, but they misspell it as project-contact-emial and then it doesn't display on the frontend and we have to spend time troubleshooting why.

@MirandaEcho any thoughts?

[joshdarby]

• form submission to project post type works well
• no weird errors
• taxonomies function as expected
• REST endpoint for projects works
• REST endpoints for taxonomies works

My only concern is the custom metabox question, and I also don't have a good answer (yet) about whether or not we want to use auth_callback.

[benlk]

maybe we should merge this (and every other PR for the project) into staging instead of master so that we're able to still merge and deploy master if something comes up.

I've updated staging to the latest master and swapped this PR to be to staging.

[benlk]

Issue created to capture the outstanding metabox work: #133