Fix SnoopCompileBot

[aminya]

Edit: fixed in https://github.com/aminya/SnoopCompileBot.jl/pull/3

• [x] To fix #111 and #105

• [x] Add workflow CI: I added workflow_CI, so we have a better idea of what is going on with SnoopCompileBot. This will prevent us from tagging broken versions from now on.

• [x] ⚠️ Should not be merged until we make sure that the online tests pass here: https://github.com/JuliaMusic/MusicXML.jl/actions?query=workflow%3ASnoopCompile

• [x] This is just a draft now, and I will experiment with different methods here. So wait until a solution is found.

We can revert the changes of Project.toml and src/SnoopCompile.jl if you prefer that. Using the workflow_CI, we can see if the package breaks by doing that.

[aminya]

This finally passes the tests https://github.com/JuliaMusic/MusicXML.jl/actions/runs/149958419. This was a cumbersome experience. 😥

This solution is very ugly :unamused:, but that is the only one I could find among all the ones you see in the commit list. Let me know if you know a better trick.

[aminya]

Because of importing conflicts, this breaks the direct use of SnoopCompileBot in the snooping script with using SnoopCompileBot in favor of the old using SnoopCompile.

Because of that, the tests here fail, but that does not matter much. Later in SnoopCompile 2, we can fix this.

For now, we can change the tests to using SnoopCompile, and test the SnoopCompileBot as part of SnoopCompile.

[aminya]

I added workflow_CI, so we have a better idea of what is going on with SnoopCompileBot. This will prevent us from tagging broken versions from now on.

We can revert the changes of Project.toml and src/SnoopCompile.jl if you prefer that. Using the workflow_CI, we can see if it breaks by doing that.

[timholy]

Superseded by #113