Reduce friction for adding temporary code to edx-platform

[robrap]

AC:

• (top priority) Create doc of the simplest way to add 2U specific code to edx-platform.
• (next priority) Create an ADR for not adding any code to edx-platform that is not core to edx-platform.
• Create follow-up ticket for better automating this process.

Notes/Questions:

• This ticket was prompted by this PR. See comment: LEARNER-8790 Support Apple team Migration openedx/edx-platform#31861 (comment).
• Is this a new ADR, or a more general version of the No New Apps ADR that is also being worked on?
• The doc should be short and sweet with bullets, and little prose. The point is to reduce fear and make this as simple as possible.
• The doc could link to other docs, but only if they are simple to follow. Also, docs that can be public should be.
• The doc can propose using edx-arch-experiments for temporary/experimental code, as long as certain rules are followed for when it will be deleted. Thought is needed for how we will track this. The doc should also explain that more permanent solutions should go into a new repo, with a link to that process.
• The doc should make it simple for someone to use the cookie cutter to create the new app.
• The doc should make it simple for someone to make a plugin. I don't think we yet have a simple doc for this.
• The doc should explain how to update the private dependency as required to get it deployed.
• The automation needs thought about what parts of this can be automated. Jeremy had thoughts on that when that ticket is created. For more permanent code where a new repo is needed, we could also automate, so we need a plan on what parts make sense to automate and prioritize each separately.

[robrap]

Additional notes:

1. Andy S. experimented with this process. See private Slack thread: https://twou.slack.com/archives/C04ACDVM6A1/p1678288563912389. We can review what went well or not.
2. We learned that arch-bom was required to merge PRs to the edx-arch-experiments project. @rgraber proposed that this should be left-as is, until we can lint for a "remove-by date", so the implementer is aware they must clean-up by a certain date. I'm not sure when and if this will be worth while implementing, but we could add to our docs on this that teams can't merge without arch-bom approval, but that the only thing we plan to review is whether or not there is a "remove-by date."

[robrap]

Relates to #422 for improving how we manage private dependencies.