macros: simplify compile-fail tests

[senekor]

I was experimenting with my solution locally and it didn't work. My solution was wrong, but the compile-fail tests didn't actually fail. I'm not 100% sure why that was the case, but I assume it's because I've set up a cargo workspace for my own exercise solutions. This moves the target folder somewhere else, but the compile-fail tests assume a specific target directory location.

Using doctests should be much more reliable, since it's using a built-in way of Rust to do this. It's a little unconventional compared to the other exercises, but so were the previous compile-fail tests.

One downside to this is that users who solve the exercise locally will have to learn a new way of un-ignoring a test. I've tried to make this smooth with appropriate comments. The test-runner should have no problems with this, since it uses cargo test -- --include-ignored to run all tests. This works for these new doctests just like for the normal ones.

[no important files changed]

[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!

[senekor]

Ugh, wait. If the test module is included in lib.rs, users could remove it to disable the tests online.

[senekor]

Also, the test runner tries to extract the body of a test to display it to users when a test fails. That wouldn't work (yet?) for these new doctests. I don't think that's a big problem, the previous snippets were not great either, since they just called another function with a file name.

[senekor]

Ugh, wait. If the test module is included in lib.rs, users could remove it to disable the tests online.

I think this true, it will enable students to cheat, technically. And it would probably be possible to fix that. i.e. mark lib.rs as a test file and provide another (e.g. src/solution.rs) file for students to write their actual solution in. But I think that would also make our automation more complicated, which assumes solutions live in lib.rs. So I'm currently leaning to just doing it this way and technically allowing students to cheat.