Add compiler path to $PATH and $CRYSTAL_EXEC_PATH for subcommands

[straight-shoota]

Resolves #15145

This patch contains a breaking change of dropping the environment variable $CRYSTAL (introduced in #14953 1.14.0) in favour of the newly added ones.

Quoting from #15145:

I think it should be acceptable to replace the $CRYSTAL variable. We could consider keeping it along, but if we do that, we'll need to do that for a long time. I think it's better to drop it in order to avoid new subcommands ever depend on it.

[straight-shoota]

I dropped the test code for exit_code because it was failing on Windows. It was unrelated to this change anyway. I'll investigate further and add it in a follow-up.

[bcardiff]

An upside of the $CRYSTAL env variable is that if the compiler is not crystal but something else crystal-1.0, crystal-1.14, crystal-2 then the external commands still works.

I don't mind prepending to the $PATH and having a $CRYSTAL_EXEC_PATH, but I don't see how we enable binaries named differently.

$CRYSTAL is also used in shards as a convention, so I thought it was convenient to keep the same pattern. (which happens to be the same as in cabal with $CABAL)

[bcardiff]

If no one thinks that supporting different names of the compiler binary is needed then 👍

[RX14]

The interface between the compiler and extension scripts is likely to be a long-lived interface, so I think it's worth spending the time to get it working when the compiler isn't named just crystal. This PR is an improvement already, but I think using $CRYSTAL is a good thing to encourage.

[straight-shoota]

CI on mingw-w64 is failing due to #15516.
This is the first time we're adding a new test for a new behaviour of the compiler executable, so it's the first time we notice that the CI workflow doesn't work correctly.

[straight-shoota]

The MinGW-W64 CI workflow appears to have even more issues: #15516 (comment)

I might try to skip this spec then so we can move forward here.