Table name shouldn't be hardcoded, though Core usually figures it out

This doesn't seem to have caused any significant issues, but it did trigger an occasional warning that I'd lost in other noise.

Detect and suppress duplicates

Detect and remove duplicate events

Fixes #7

Turns out, there's no harm in letting it run for CLI commands

Improve caching and event CPT handling

Plugin needs to create entries before `init`, and expects a certain `post_name`, warranting this approach

Update CPT entries directly, rather than through Core's cron functions 

Add native caching

Reduces possibility for race conditions when multiple jobs run at once

Until now, the CPT has been an independent part of this plugin, something that theoretically could've been disabled without impacting plugin functionality. However, race conditions prevent the plugin's use without the CPT, so it must be integrated more-deeply with the event-execution portion of the plugin.

Since we often query directly, it was foolish of me to omit this both because Core's caching is often bypassed, and because it won't be reliable.

Like we do when checking if a job exists, retrieving jobs should also query directly to avoid caching such as what Advanced Post Cache provides.

Set proper status codes for REST API responses

Avoids sending default of `500`

Initial commit

This reverts commit 1d5245a3.

Restores part of b3bf2e8a

This reverts commit b3bf2e8a.

Was meant to be a patch commit

See 07ea030a

Can't call `wp_trash_post()` before `init` because it relies on `wp_insert_post()`, which performs capabilties checks.

Core's normal handling would result in too many deletes at a time

Review feedback: trash posts for faster processing and deferred removal, and use a Core function to find an event as it can be used before init and includes caching

Also, explicitly reference secret from global scope, for consistency throughout plugin