Refactor dot-dsl tests

[angelikatyborska]

Changes inspired by this forum post: https://forum.exercism.org/t/dot-dsl-duplicate-test/18938

Note that this exercise doesn't have canonical data.

What I have done:

• Solved the duplicate test problem from the forum post by changing the test invalid statement: graph with no keywords to use graph() in the graph, not Enum.map()
• Renamed a few tests to no longer mention "without space". The original intended syntax "with spaces", like graph [foo: "bar"] is no longer encouraged in Elixir. It got automatically reformatted to a regular call with parenthesis in this giga PR: 771a49c#diff-ebb08554f0f8f470024408d2abdabaa480671a429f693afe56cc86eff923b1e4 In the same PR, the syntax "without space" got changes from graph[foo: "bar"] to graph[[foo: "bar"]]. WIth autoformatting, it no longer makes sense to talk about "with spaces" or "without spaces". I renamed those tests to "not a call".
• I added 3 extra tests, for graph, node, and edge, where the corresponding macros receive a string instead of a list ("invalid graph attribute syntax: wrong argument type" etc.)
• I reordered the tests so that all tests for invalid node syntax are next to one another etc., this is why the git diff is so messed up 😢

[github-actions]

This PR touches files which potentially affect the outcome of the tests of an exercise. This will cause all students' solutions to affected exercises to be re-tested.

If this PR does not affect the result of the test (or, for example, adds an edge case that is not worth rerunning all tests for), please add the following to the merge-commit message which will stops student's tests from re-running. Please copy-paste to avoid typos.

[no important files changed]

For more information, refer to the documentation. If you are unsure whether to add the message or not, please ping @exercism/maintainers-admin in a comment. Thank you!

[github-actions]

Thank you for contributing to exercism/elixir 💜 🎉. This is an automated PR comment 🤖 for the maintainers of this repository that helps with the PR review process. You can safely ignore it and wait for a maintainer to review your changes.

Based on the files changed in this PR, it would be good to pay attention to the following details when reviewing the PR:

• General steps

  • 🏆 Does this PR need to receive a label with a reputation modifier (x:size/{tiny,small,medium,large,massive})? (A medium reputation amount is awarded by default, see docs)

• Any exercise changed

  • 👤 Does the author of the PR need to be added as an author or contributor in <exercise>/.meta/config.json (see docs)?
  • 🔬 Do the analyzer and the analyzer comments exist for this exercise? Do they need to be changed?
  • 📜 Does the design file (<exercise>/.meta/design.md) need to be updated to document new implementation decisions?

• Practice exercise changed

  • 🌲 Do prerequisites, practices, and difficulty in config.json need to be updated?
  • 🧑‍🏫 Are the changes in accordance with the community-wide problem specifiations?

• Practice exercise tests changed

  • ⚪️ Are all tests except the first one skipped?
  • 📜 Does <exercise>/.meta/tests.toml need updating?

---

Automated comment created by PR Commenter 🤖.