consider making each exercise's test generator its own binary instead of all in one generator binary

[petertseng]

Preface: If you're an incoming maintainer to this track and wondering how highly to prioritise this issue, exercise test generators are not student-facing, so you should focus on the student-facing issues first. Of course, the tests thereby generated are student-facing, but so long as #260 gets solved, the generators will be runnable, and as long as that's true then the compilation time and improvements to the generators (which would be two things solving this issue makes easier) are not the highest priority for this track.

---

Currently all generators get compiled into https://github.com/exercism/crystal/blob/main/generator/generator.cr which uses a command-line argument to determine which generator to run. This means that if even one generator fails to compile, none of them can be run. It's my opinion that this impedes improvements to the generators for two reasons:

1. For changes that could apply to all generators, it requires changes to be made to all the generators instead of allowing generators to be improved one at a time, as time allows.
2. For a contributor who just wants to make a change to one generator, build it, and test it to see whether the generator still works, they are required to wait for the compilation time of all generators instead of just the generator they changed.

For these reasons, I think the idea of making each generator its own binary should be seriously considered.

I understand it's not my place to tell a maintainer how to run their track; I simply present the idea to be judged on its merits.

I'm especially aware of the common advice that "if you don't understand why it is the way it is, you have no right to suggest any changes". Let me suggest that from reading the comments in #52 that the reason it is the way it is is because that's how they did it in the Ruby track. However, Crystal, a compiled language, is subject to these additional considerations that don't affect Ruby, an interpreted language. Of course, an incoming maintainer is empowered to read #52 and judge for themself whether I've correctly understood why things are they way they are now.