chore: local development improvements

[aduane]

This PR makes several changes with the goal of improving the plugin development workflow. (Development of plugins, not development of the SDK or the plugin runner)

Changes:

1. Starting the plugin runner without PLUGIN_RUNNER_SIGNING_KEY being set emits a warning with instructions on how to eliminate the message instead of raising an exception. (7ef6fb7)
2. Event fixtures are now shipped with the CLI, and can be referenced by the event name. We still offer the ability for users to provide their own event fixture file. We first look for a matching path, if we can't find one we assume the CLI parameter is the name of an event and attempt to look for a Canvas-provided event fixture instead. If nothing can be found, an error message is shown instead of an exception.
3. If the emit CLI command can't connect to a running plugin runner process, an error message is shown instead of an exception.
4. Running the plugin runner from the CLI. (Start the plugin runner in one terminal, emit to it from another)

Still working on:

1. Making data accessible without access to a Canvas EMR database. (Substitute a sqlite database seeded with data and provide a way to add/modify the data) Out of scope, will work on this in a separate PR.

[csande]

Idea for consideration:

Rather than making developers start the plugin runner and then emit to it, what if you combine those into a single subcommand called "test_plugin"? This command would start the plugin runner in a subprocess, emit the event, and then stop the plugin runner.

I could see the iteration cycle where you have to start, emit, stop, edit, and repeat being mildly annoying (and maybe requiring multiple terminal windows), whereas if you combined start, emit, and stop into a single subcommand, your iteration cycle would just be test, change, and repeat.

[aduane]

Idea for consideration:

Rather than making developers start the plugin runner and then emit to it, what if you combine those into a single subcommand called "test_plugin"? This command would start the plugin runner in a subprocess, emit the event, and then stop the plugin runner.

I could see the iteration cycle where you have to start, emit, stop, edit, and repeat being mildly annoying (and maybe requiring multiple terminal windows), whereas if you combined start, emit, and stop into a single subcommand, your iteration cycle would just be test, change, and repeat.

I would like to improve the constant start, emit, stop, edit, and repeat by (at some future date) using something like https://github.com/gorakhargosh/watchdog to watch the directories of the plugins for changes and reloading them as a result.

I also would like to keep in mind iteration workflows that depend on multiple events firing in a sequence.