Migrate from SnoopPrecompile to PrecompileTools

[timholy]

This pull request migrates the package from SnoopPrecompile to PrecompileTools.
PrecompileTools is nearly a drop-in replacement except that there are changes in naming and how developers locally disable precompilation (to make their development workflow more efficient). These changes are described in PrecompileTool's enhanced documentation, which also includes instructions for users on how to set up custom "Startup" packages, handling precompilation tasks that are not amenable to workloads, and tips for troubleshooting.

Why the new package? It meets several goals:

• The name "SnoopPrecompile" was easily confused with "SnoopCompile," a package designed for analyzing rather than enacting precompilation.
• SnoopPrecompile/PrecompileTools has become (directly or indirectly) a dependency for much of the Julia ecosystem, a trend that seems likely to grow with time. It makes sense to host it in a more central location than one developer's personal account.
• As Julia's own stdlibs migrate to become independently updateable (true for DelimitedFiles in Julia 1.9, with others anticipated for Julia 1.10), several of them would like to use PrecompileTools for high-quality precompilation. That requires making PrecompileTools its own "upgradable stdlib."
• We wanted to change the use of Preferences to make packages more independent of one another. Since this would have been a breaking change, it seemed like a good opportunity to fix other issues, too.

For more information and discussion, see this discourse post.

[github-actions]

Benchmark Results

	master	641180a...	t[master]/t[641180a...]
search/multithreading	0.0218 ± 0.00039 h	0.0211 ± 0.00073 h	1.03
search/serial	0.0233 ± 0.00019 h	0.0233 ± 0.00015 h	0.999
time_to_load	21.4 ± 0.72 s	20.8 ± 0.19 s	1.03

Benchmark Plots

A plot of the benchmark results have been uploaded as an artifact to the workflow run for this PR.
Go to "Actions"->"Benchmark a pull request"->[the most recent run]->"Artifacts" (at the bottom).

[timholy]

Not sure if you know this, but PrecompileTools is already configurable with a Preferences variable: https://julialang.github.io/PrecompileTools.jl/stable/#Package-developers:-reducing-the-cost-of-precompilation-during-development

[MilesCranmer]

Thanks, that is useful! Is there a way I can also force the precompilation code to run during tests? The reason I have this maybe_compile_workload is so that I can trigger the precompilation code during my testing, so it shows up on code coverage.

[timholy]

Is there a way I can also force the precompilation code to run during tests?

Sadly, no, it only runs when the package is being precompiled. So you may need your modifications anyway.