Proof of concept: using djp for plugin management

[cc-a]

This PR shows the minimal initial steps required to support plugins using djp. To try it out:

• Checkout this branch and pip install . to update with the added dependencies.
• Pip install the example plugin I've created at cc-a/coldfront_djp_plugin (pip install git+https://github.com/cc-a/coldfront_djp_plugin.git).
• Run coldfront showplugins to see the plugin just installed.
• Run coldfront migrate and note that the migration from the plugin is applied.
• Start the development server and open http://localhost:8000/djp-plugin/.

Some thoughts:

• The main takeaway from this PR seems to be that using djp is very simple both from the coldfront and plugin side.
• The steps to port existing third party plugins would be fairly trivial. They'd just need to implement the relevant hooks as in the example init.py and add an entrypoint.
• The placement of shipped plugins as in coldfront/plugins is not well supported by djp so they would likely need to be refactored as regular Django apps within the wider codebase. This would be necessary to be able to remove the existing plugin infrastructure,
• Local co-development of plugins and coldfront could still be facilitated by cloning apps into the plugin dir then using pip install -e to allow plugin discovery.
• The existing plugin infrastructure could be deprecated (with warnings added to the codebase) for a period before its removal to create a smoother transition for plugin developers.

[aebruno]

@cc-a Tested this out and works great. Thanks for including the example plugin. I really like the simplicity and should be easy to port the existing core plugins. After playing with this a bit, one concern I have is that any (detected) pip installed plugin is automatically configured/executed. This feels dangerous and would be great if there was a way to configure which plugins were active. This seems to be on their radar.