Modularize `flavors` and `base` apps

[modulitos]

We need better dependency management for our flavors and base apps. These currently exist as separate Django applications, where each flavor lives as a folder under our flavors app. This is creating a monolithic repo, which contains all flavors, and does not manage the dependencies of each flavor with the base flavor.

To fix this, our flavors and our base apps should be modularized, where a flavor app requires the base app dependency, and uses semantic versioning to do so. So I think we should package each flavor that has custom code separately under it's own repo and it should extend our base flavor.

We can do this using Django apps. But since we are moving towards a static site (#655), I think we should finish that issue first, then modularize our flavors using npm modules. We'll still need to figure out a proper API for extending our base module, but I imagine the solution will still involve extending Backbone views as we are currently doing.

So I propose the following TODO's (feel free to update these as needed):

• Complete #655
• Create a spec that outlines and API for our base module, and some examples around how a flavor module containing custom code will extend the base module.

[zmbc]

[continuing discussion from #655]

That is a fair point. An API that we could use would be great, although I wonder how difficult it would be to abstract something like that effectively? To take a specific example, think about the feature in the pboakland flavor that swapped the show list button and add a place button when a page was open, then swapped them back when a page was closed. Making that work involved tweaking and overriding several methods inside the app view. To abstract something like that, I feel like we'd need generic "insert button" and "hide button" api calls, combined with events we can listen to that signal state changes (user opened a page, user closed a page, etc.). All of which would be great, but the use case is pretty specific.

Any API that would solve this use case without giving the user the full power of code would be a mess, obviously. :rofl: Examples like these are good things to think about. Can we come up with a coherent, small set of changes that will cover 75% of customizations people want? (Note that this isn't entirely separate from the design of the config--in fact, they're almost the same thing.) I'm not sure what the answer to that question is. If it's "no," then it's probably not worth implementing at all.