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

Note: See https://github.com/openedx/openedx-events/issues/421#issuecomment-2488837239 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.

Start with the linked openedx-events issue comment and the edx-platform code search for plugin_app to understand the existing patterns and their historical rationale. The ADR should document the current state, explain when plugin patterns are unnecessary, and provide guidance for avoiding or cleaning up this usage.