Establish a process for enterprise enhancements and API changes

[vallis]

Over the last few months we have seen PRs from non-core developers adding features to enterprise and potentially changing the API. These contributions can be very valuable, but we need to find a way to manage them in a way that preserves backward compatibility, as well as the "oneness" of enterprise's design.

As part of this, we probably want to revisit the documentation regarding the core design, and add detail to "how to contribute". What else? We would

• encourage very modular PRs;
• move some features that now are unique but may have multiple variants into enterprise_extensions; or alternatively structure them as plugins (e.g., there's only one ephemeris model right now, but there can be many);
• establish a formal review process.

What else?

[vhaasteren]

We definitely also need to require documentation of PRs. By always updating the docs as part of a PR, we would always have up-to-date documentation. But it'll take some effort to bootstrap.

I like the plugin idea of modular or overly complicated functionality. I think the fastshermanmorrison ECorrKernel addition fits in that category.

The formal review process, and related Enterprise dev processes we should probably discuss. We only have a slack channel in nanograv at the moment that also includes users. Perhaps we can have a dedicated channel or a mailing list? Since this piece of code falls under the nanograv umbrella, and we only have nanograv devs, I think it's safe to opt for a slack channel there.