Document changes to exercises

[emcoding]

(This came up in #980, copied here)

I asked:

Shouldn't we start to document which changes/exercises have been considered for implementation or discussed previously? So that (new) contributors can see if exercises are rejected as possible candidates, and not put in the work.

@kotp's suggestions:

We could have a ".rejected_exercises" file, that we can list.

Though, before implementing exercises as a pull request, there should probably be an issue created. Where we can verify the points that it teaches, etc., then we can approve the addition, or reject the addition. It may still get to the PR stage, but at least we can tag the issue as "Won't Implement" by tag, and the PR as well.

I like the rejected_exercises file in combination with an issue that we can point to.

Let's also point to the file in the Readme
And I'd like to extend the file (can be done later) with information on what other changes are considered and rejected, and if exercises can't be autogenerated due to changes to ProbSpec.
Do we want all of that in one file?

That's because I'm also looking at #935 with the list of exercises we don't accept changes for.

---

WIP Todo's

• Create file with exercises that we have discussed and decided not to add to the Ruby Track
• Create an issue that points to that file, the label
• Create a label (with a link to the file)
• Update Readme/contributing with a reference to the file and the new issue
• (Reference it in our future PR template Add PR template #925)

---

@exercism/ruby

[kytrinyx]

We are adding an optional design.md file to exercise specifications in problem-specifications.
We can also use this in this repository (for exercises that are independent of the problem-specifications repository).
exercism/problem-specifications#2108