Added the test-cases from canonical-data.json to exercise diamond

[eklatzer]

Hey, I have done the following steps:

• added a test-case generator for the test-cases defined in canonical-data.json in gen.go
• regenerated the tests.toml using configlet
• generated the cases_test.go using the gen.go
• added func TestDiamond using this test-cases

I additionally adjusted the existing tests, as they expected a \n at the end. Regarding to the instructions.md there should not be a new-line at the end, for example:
Diamond for letter 'E':

····A····
···B·B···
··C···C··
·D·····D·
E·······E
·D·····D·
··C···C··
···B·B···
····A····

Reach out to me if this change should be reverted and a \n should be expected at the end.

Closes #2222

[github-actions]

Dear eklatzer

Thank you for contributing to the Go track on Exercism! 💙
You will see some automated feedback below 🤖. It would be great if you can make sure your PR covers those points. This will save your reviewer some time and your change can be merged quicker.

• ⬆️ The instructions and test cases for many practice exercises originate in the Exercism-wide problem-specifications repo. If the exercise you changed is listed there in the exercises folder, please consider the following.

  • Improvements to the instructions.md file should be made in the problem-spec repo so that all tracks can benefit.
    You can open a PR there instead.
  • If you want to add some language specific information, use the instructions.append.md file (see Practice Exercise Docs).
  • Test cases selected in the .meta/tests.toml file need to be implemented in the <exercise>_test.go file according to the specification in canonical-data.json.

• 🔗 If your PR fully fixes an issue, please include the text Fixes #issue_no in any line of the PR description. This will make the issue be automatically be closed when the PR is merged. If your PR is related to an existing issue but does not fix it completely, please link the issue anywhere in the description of the PR with #issue_no. You can read more about this in Github: Linking a pull request to an issue

• ✍️ If your PR is not related to an existing issue (and is not self-explaining like a typo fix), please make sure the description explains why the change you made is necessary.

• 🔤 If your PR fixes an easy to identify typo, if would be great if you could check for that typo in the whole repo. For example, if you found Unicdoe, use "replace all" in your editor (or command line magic) to fix it consistently.

Dear Reviewer/Maintainer

• 📏 Make sure you set the appropriate x:size label for the PR. (This also works after merging, in case you forgot about it.)

• 🔍 Don't be too nit-picky. If the PR is a clear improvement compared to the status quo, it should be approved as clear signal this is good to be merged even if the minor comments you might have are not addressed by the contributor. Further improvement ideas can be captured in issues (if important enough) and implemented via additional PRs.

• 🤔 After reviewing the diff in the "Files changed" section, take a moment to think about whether there are changes missing from the diff. Does something need to be adjusted in other places so the code or content stays consistent?

_{Automated comment created by PR Commenter 🤖.}

[eklatzer]

Maybe also interesting for #605

[andrerfcsantos]

Left some comments.

Reach out to me if this change should be reverted and a \n should be expected at the end.

Let's revert it from now. The change might have some merits, but it is a big change, since it will make all current solutions fail the tests. Let's discuss it separately. Feel free to create a new issue about this after reverting the change.

[andrerfcsantos]

Some more suggestions

[andrerfcsantos]

Great!