Create ADR for avoiding use of plugin patterns where they are not needed

[robrap]

Note: See openedx/openedx-events#421 (comment) for @kdmccormick's initial comments on this topic.

Inside edx-platform, many apps make use of plugin patterns. For examples, see https://github.com/search?q=repo%3Aopenedx%2Fedx-platform+plugin_app&type=code.

Use of this pattern predate ADRs, but @kdmccormick's memory of the reasoning at the time was something like:

• If we turn built-in edx-platform djangoapps into plugins, then it'll make them easier to extract.
• If edx-platform repo developers dogfooded the django plugin system, they would learn it and contribute to it.
• Built-in XBlocks are still XBlocks, so built-in Django apps should still be plugins.

From a comment in the linked ticket, @kdmccormick added:

I could write more about why I disagree with each of those, but to be brief, I think that building internal apps as django plugins has just led to a stranger, more-indirect codebase with a higher barrier to entry for new maintainers.

This issue is about writing an ADR in edx-platform for what we want, providing context of how things are, and helping stop the pattern and potentially clean-up from the use of this past pattern.

[robrap]

@kdmccormick: I know you didn't want the edx-platform roadmap issue to be an index into every possible ticket. We can discuss if this would be useful for making the platform more understandable.